From ghc-devs at haskell.org Tue Jan 1 06:48:06 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 06:48:06 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.d36489ca206a6d27afcb8ff1c642eaa7@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): moving the functions and types relating to `FractionalLit` causes a bunch of errors after running `./boot && ./configure && make -j4` ... I'll paste them below. It seems like the `GHC.Real` that's imported into `BasicTypes` is not the one that I've added things to in `libraries/base/GHC/Real.hs` however after talking to bgamari the other day he seemed to be sugesting that this was the only one that gets bootstrapped, so I'm pretty confused. All I did was change the import to `import GHC.Real hiding (infinity)` and I would have thought it'd import everything needed. Obviously something's wrong with my assumption there somewhere, because `FractionalLit` is *definitely* at the bottom of the `GHC.Real` module, and AFAICS it's exporting everything (no explicit exports) Can anyone give me some direction about how I can understand enough to learn how to understand what's wrong here, and how to fix it? {{{ compiler/basicTypes/BasicTypes.hs:100:26: error: Not in scope: type constructor or class ‘FractionalLit’ Perhaps you meant ‘Fractional’ (imported from GHC.Real) | 100 | IntegralLit(..), FractionalLit(..), FractionalExponentBase(..), | ^^^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:100:45: error: Not in scope: type constructor or class ‘FractionalExponentBase’ | 100 | IntegralLit(..), FractionalLit(..), FractionalExponentBase(..), | ^^^^^^^^^^^^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:101:28: error: Not in scope: ‘negateFractionalLit’ | 101 | negateIntegralLit, negateFractionalLit, | ^^^^^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:102:24: error: Not in scope: ‘mkFractionalLit’ | 102 | mkIntegralLit, mkFractionalLit, mkTHFractionalLit, rationalFromFractionalLit, | ^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:102:41: error: Not in scope: ‘mkTHFractionalLit’ | 102 | mkIntegralLit, mkFractionalLit, mkTHFractionalLit, rationalFromFractionalLit, | ^^^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:102:60: error: Not in scope: ‘rationalFromFractionalLit’ | 102 | mkIntegralLit, mkFractionalLit, mkTHFractionalLit, rationalFromFractionalLit, | ^^^^^^^^^^^^^^^^^^^^^^^^^ compiler/basicTypes/BasicTypes.hs:103:9: error: Not in scope: ‘integralFractionalLit’ | 103 | integralFractionalLit, | ^^^^^^^^^^^^^^^^^^^^^ <> make[1]: *** [compiler/stage1/build/BasicTypes.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 07:47:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 07:47:01 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.26492077a1198115ad1378fbcf768091@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I duplicated the library code into both `GHC.Real` and left it in `BasicTypes.hs` as well as per osa1's suggestion on IRC. Got this error after running `./boot && ./configure && make -j4` {{{ libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs:5:1: error: Bad interface file: libraries/ghc-prim/dist-install/build/GHC/Tuple.hi mismatched interface file versions (wanted "80720181230", got "80720181219") | 5 | import GHC.Tuple () | ^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 08:22:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 08:22:16 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.056b2334a93cbaf1e79bc10d2bc5c032@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Just in case, doing `make maintainer-clean` sometimes helps when changes don't seem to propagate correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 08:38:31 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 08:38:31 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.a3a13aeb8c09f212e3416d69078727e8@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Thanks os1. I did `make clean`. Then the error became: {{{ libraries/base/GHC/Real.hs:839:21: error: Not in scope: type constructor or class ‘SourceText’ | 839 | = FL { fl_text :: SourceText -- How the value was written in the source | ^^^^^^^^^^ libraries/base/GHC/Real.hs:849:25: error: Not in scope: type constructor or class ‘SourceText’ | 849 | | THFL { thfl_text :: SourceText -- How the value was written in the source | ^^^^^^^^^^ }}} and a bunch more errors of a similar type... at which point you suggested removing `SourceText`, but that'd require rewriting all the functions, so ... yeah, now I believe you're looking up the ticket again and refreshing your brain with it :) :thx: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 09:50:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 09:50:12 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.19f845e2a171391293901d0cd784efd7@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Is the last version you are talking about on Gitlab already? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 09:59:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 09:59:52 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.d197932970970a3a227febb4315c7514@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): It's currently on gitlab, ulysses4ever -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 10:11:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 10:11:02 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.a2b31988d168f2321052012c1934850c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I added a comment on gitlab MR. Let's maybe continue discussing there as it also shows the code and makes things easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 12:31:35 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 12:31:35 -0000 Subject: [GHC] #16048: Show Instance for IOException discards error code In-Reply-To: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> References: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> Message-ID: <064.7abab6d667c0cd13cdfc1e5aa4334a9f@haskell.org> #16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by makos): I can provide example outputs based on compiled ghc (old/new): Original behaviour: {{{ System.Directory.renameFile "a.a" "" *** Exception: a.a: renameFile:renamePath:rename: does not exist (No such file or directory) }}} Updated behaviour: {{{ System.Directory.renameFile "a.a" "" *** Exception: a.a: renameFile:renamePath:rename: does not exist (2) (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 16:08:05 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 16:08:05 -0000 Subject: [GHC] #15873: move to llvm 7 for 8.8.1 In-Reply-To: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> References: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> Message-ID: <060.6392c55a8d6b48271f85eb3045eac171@haskell.org> #15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): FWIW, llvm 7.0.1 seems to work with ghc 8.6.3 but I haven't done extensive testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 16:26:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 16:26:52 -0000 Subject: [GHC] #15873: move to llvm 7 for 8.8.1 In-Reply-To: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> References: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> Message-ID: <060.2d7b8346c0ac6a28021ed023529da604@haskell.org> #15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): FWIW, llvm 7.0.1 seems to work with ghc 8.6.3 but I haven't done extensive testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 17:24:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 17:24:50 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.1804545be2e09741e15f2fc329ec3a64@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: watashi (added) * status: closed => new * resolution: fixed => Comment: Unfortunately it Phab:D5169 did not appear to fix this in all cases: the binary distributions produced by CI using the `perf` flavour still fail in `make install` with: {{{ "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/home/ben/tmp2/ghc-8.7.20181230/hi' '/home/ben/tmp2/ghc-8.7.20181230/hi/lib/ghc-8.7.20181230' '/home/ben/tmp2/ghc-8.7.20181230/hi/share/doc/ghc-8.7.20181230/html/libraries' 'v p dyn' Installing library in /home/ben/tmp2/ghc-8.7.20181230/hi/lib/ghc-8.7.20181230/ghc-prim-0.5.3 dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 17:35:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 17:35:08 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.4c6303780a8d51c3839ad66f34c6aafc@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5169 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed `libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o` exists but `libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o` does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 18:02:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 18:02:10 -0000 Subject: [GHC] #4450: Do stack squeezing before expanding stack In-Reply-To: <046.3864b3bc99473fda6ed91f5139d60907@haskell.org> References: <046.3864b3bc99473fda6ed91f5139d60907@haskell.org> Message-ID: <061.5a9fa64e5e9474628cbed442ffe0756e@haskell.org> #4450: Do stack squeezing before expanding stack -------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Sebastian Graf ): In [changeset:"e2d614e40e8b049ac0bcf3c6ccc6f0009864511e/nofib" e2d614e/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="e2d614e40e8b049ac0bcf3c6ccc6f0009864511e" Disable timer-based context switches Summary: In the past, we repeatedly had problems with non-deterministic allocations due to stack squeezing during context switches (#4450, #8611). This patch adds `+RTS -V0 -RTS` as extra `RUNTEST_OPTS` for every single- threaded benchmark. Is this the right place to add the flags? Should we also do this for all the other benchmarks? Reviewers: simonmar, osa1, nomeata, O26 nofib GHC Trac Issues: #8611 Differential Revision: https://phabricator.haskell.org/D5470 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 18:02:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 18:02:10 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.3f9d9fb3606abfc2088c11300e2bc68b@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 #16065 | Differential Rev(s): Phab:D5470 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"e2d614e40e8b049ac0bcf3c6ccc6f0009864511e/nofib" e2d614e/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="e2d614e40e8b049ac0bcf3c6ccc6f0009864511e" Disable timer-based context switches Summary: In the past, we repeatedly had problems with non-deterministic allocations due to stack squeezing during context switches (#4450, #8611). This patch adds `+RTS -V0 -RTS` as extra `RUNTEST_OPTS` for every single- threaded benchmark. Is this the right place to add the flags? Should we also do this for all the other benchmarks? Reviewers: simonmar, osa1, nomeata, O26 nofib GHC Trac Issues: #8611 Differential Revision: https://phabricator.haskell.org/D5470 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 18:55:57 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 18:55:57 -0000 Subject: [GHC] #16118: SYB link in Data.Data is dead Message-ID: <045.8bbd8a67c43b7423e7fe4ecadaf4cfc6@haskell.org> #16118: SYB link in Data.Data is dead -------------------------------------+------------------------------------- Reporter: ocramz | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The link to the SYB blog given in the Data.Data haddocks (http://foswiki.cs.uu.nl/foswiki/bin/view/GenericProgramming/SYB) is dead. Is there a backup copy somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 19:46:43 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 19:46:43 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.2bcf091a3a45d3956e65586fa015360b@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5169 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I built a `BuildFlavour=perf` build locally and found that while `libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o` was indeed built, it was not included in the binary distribution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 1 20:12:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Jan 2019 20:12:10 -0000 Subject: [GHC] #16103: docs-haddock Hadrian target doesn't work reliably In-Reply-To: <050.924a903dce685538d1f289c25038f6ec@haskell.org> References: <050.924a903dce685538d1f289c25038f6ec@haskell.org> Message-ID: <065.c7f08e61db7de6b79ae6d74b13132c98@haskell.org> #16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 03:09:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 03:09:51 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.712d74245115b76f978fe1e1a7594549@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5169 Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): Attempt to address this in https://gitlab.haskell.org/ghc/ghc/merge_requests/65 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 04:32:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 04:32:05 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.d74351e5be15b76c9546054a8faf7f6b@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The culprit is [http://git.haskell.org/ghc.git/blob/ae4f1033cfe131fca9416e2993bda081e1f8c152:/compiler/rename/RnSource.hs#l774 these lines of code] in `rnFamInstEqn`: {{{#!hs ; let bad_tvs = maybe [] (filter is_bad . snd) mb_cls var_name_set = mkNameSet (map hsLTyVarName bndrs' ++ all_imp_var_names) is_bad cls_tkv = cls_tkv `elemNameSet` rhs_fvs && not (cls_tkv `elemNameSet` var_name_set) ; unless (null bad_tvs) (badAssocRhs bad_tvs) }}} `a` //is// in scope over that type family equation, but it's spuriously rejected by this validity check. This check assumes that if a type family equation has an explicit forall, then every type variable on the RHS must either be: 1. Explicitly bound by the `forall`, or 2. Implicitly bound (e.g., as a kind variable) But the sort of program above presents a third option: 3. It's explicitly bound by the class instance, but not by the family equation's `forall`. Unfortunately, this validity check doesn't take this option into account, as evidenced by the implementation of `var_name_set`. I was able to fix this program (and pass GHC's test suite) by changing `var_name_set` to this: {{{#!diff diff --git a/compiler/rename/RnSource.hs b/compiler/rename/RnSource.hs index c76eb31abc..e42f79bd45 100644 --- a/compiler/rename/RnSource.hs +++ b/compiler/rename/RnSource.hs @@ -772,8 +772,9 @@ rnFamInstEqn doc mb_cls rhs_kvars -- See Note [Renaming associated types] ; let bad_tvs = maybe [] (filter is_bad . snd) mb_cls - var_name_set = mkNameSet (map hsLTyVarName bndrs' - ++ all_imp_var_names) + var_name_set = extendNameSetList pat_fvs $ + map hsLTyVarName bndrs' ++ + all_imp_var_names is_bad cls_tkv = cls_tkv `elemNameSet` rhs_fvs && not (cls_tkv `elemNameSet` var_name_set) ; unless (null bad_tvs) (badAssocRhs bad_tvs) }}} I'm not sure if this is the correct approach, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 04:32:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 04:32:10 -0000 Subject: [GHC] #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc Message-ID: <048.1114bd71ff6c08fce3ce4e70e0b03476@haskell.org> #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In base-4.12, `throw` goes from {{{#!hs throw :: Exception e => e -> a }}} to {{{#!hs throw :: forall (r :: RuntimeRep). forall (a :: TYPE r). forall e. Exception e => e -> a }}} http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Exception- Base.html#v:throw Similar story for `undefined`. Even as a fairly experienced haskell programmer I find the signature difficult to parse, leaving aside the meaning of `RuntimeRep` and `TYPE`. The amount of research an expert in Haskell 98 would have to do to thoroughly understand that signature is unreasonable (the various meanings of `forall`, `DataKinds`, as well as the levity polymorphism stuff). I don't have a proposed solution, but a constraint synonym or something that hid `RuntimeRep` and `TYPE`, and which could be documented with "This means a type with any runtime representation; everything is fine" would be okay. Relevant: https://ghc.haskell.org/trac/ghc/ticket/12030 https://ghc.haskell.org/trac/ghc/ticket/11549 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 10:21:55 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 10:21:55 -0000 Subject: [GHC] #15914: haddock-library-1.7.0 fails to build on ppc64 BE In-Reply-To: <050.f395dc81b971adf8bf5a08abf481d621@haskell.org> References: <050.f395dc81b971adf8bf5a08abf481d621@haskell.org> Message-ID: <065.54e980573e9df217aa0a0fa1d349dae8@haskell.org> #15914: haddock-library-1.7.0 fails to build on ppc64 BE -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #15411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => closed * resolution: => duplicate * related: => #15411 Comment: This looks like a duplicate of #15411. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 12:37:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 12:37:35 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary Message-ID: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with {{{-c}}} (Migrated from https://github.com/snowleopard/hadrian/issues/706) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 12:41:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 12:41:35 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.14f98c686f6b1b5589714e4c5835dd80@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): hvr suggests using {{{ $ cabal new-exec --project=$PWD/hadrian/cabal.project sh -- -c 'command -v alex' /home/hvr/.cabal/store/ghc-8.4.4/alex-3.2.4-4006f020d0bf93fca9fc50e9f961c4a2af3341f7a44d2bfa6f7feb9c7d6e930b/bin/alex }}} or {{{ $ cabal new-exec --project=$PWD/hadrian/cabal.project which -- alex /home/hvr/.cabal/store/ghc-8.4.4/alex-3.2.4-4006f020d0bf93fca9fc50e9f961c4a2af3341f7a44d2bfa6f7feb9c7d6e930b/bin/alex }}} To find the build-tools. Is it possible for hadrian to call cabal in this way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 12:47:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 12:47:08 -0000 Subject: [GHC] #16121: testsuite: only_ways(llvm_ways) behaves strangely Message-ID: <048.2fa6281b8f81542d6594f7dd14ed320e@haskell.org> #16121: testsuite: only_ways(llvm_ways) behaves strangely -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that specifying `only_ways(llvm_ways)` for tests is not sufficient. E.g. when looking for the test T8131 in the llvm-CI-runner's logs, you won't find it. It is written like this: {{{#!python test('T8131', [cmm_src, only_ways(llvm_ways)], compile_fail, ['']) }}} The only `optllvm`-way tests are on `validate-aarch64-linux-deb9` {{{ =====> T5681(optllvm) 2409 of 6747 [0, 83, 8] cd "llvm/should_compile/T5681.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T5681.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm =====> T6158(optllvm) 2410 of 6747 [0, 83, 8] cd "llvm/should_compile/T6158.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T6158.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm -package vector -package primitive =====> T7571(optllvm) 2411 of 6747 [0, 83, 8] cd "llvm/should_compile/T7571.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T7571.cmm -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm -no-hs-main =====> T8131b(optllvm) 2413 of 6747 [0, 83, 8] cd "llvm/should_compile/T8131b.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T8131b.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O -fllvm =====> T11649(optllvm) 2414 of 6747 [0, 83, 8] }}} These are triggered by the magic incantation: {{{#!python def f( name, opts ): opts.only_ways = ['optllvm', 'llvm', 'debugllvm'] setTestOpts(f) }}} `validate-x86_64-linux-deb9-llvm` won't even test those... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 14:12:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 14:12:17 -0000 Subject: [GHC] #13951: InScope set assertion failure from monad-skeleton In-Reply-To: <049.5db03d032e7f17d002eb17274d5a81f3@haskell.org> References: <049.5db03d032e7f17d002eb17274d5a81f3@haskell.org> Message-ID: <064.864ae5a1dc33081ee09c473014e9a93a@haskell.org> #13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I've reduced to: {{{ #!hs {-# LANGUAGE PolyKinds, Rank2Types #-} module T13951 where viewL :: forall k. Bool -> (forall x. k x -> Int) -> Int viewL False _ = 0 viewL True r = r undefined }}} (note this is now a warning, not an assertion failure) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 16:22:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 16:22:20 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.8a1b47de37ffce12712f3b1bf578436a@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T13839 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5449 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Roland, can you move the patch to Gitlab? We're much more active there and I think people will miss the patch or forget about it if it stays on Phabricator. We should get some feedback on the proposed behavior in comment:5 vs. the current behavior before reviewing. Personally I don't find the current behavior confusing, but maybe because I'm accustomed to it already. Not sure what's a good platform for this kind of discussion though.. (maybe haskell-cafe?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 17:23:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 17:23:20 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.8a859c880238edb36eedcae5c4853601@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Yes, we can run these Cabal commands and obtain the output using Shake's `cmd` function: https://hackage.haskell.org/package/shake-0.17.3/docs/Development- Shake.html#v:cmd In particular, see the example with `Stdout out <- cmd ...`. However, this makes Cabal a dependency of Hadrian even for users who are building Hadrian using Stack (e.g. using the `build.stack.bat` script). Could we instead use Hadrian's built-in path resolver `lookupInPath`? Have a look here: https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/src/Hadrian/Oracles/Path.hs#L18-22 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 17:49:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 17:49:12 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.b6cf870d5abbe48caa32ea8ad2e6c60a@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): Unless I am misunderstanding this would be exactly the same behaviour as default ./configure which will look for alex and happy in path, the issue brought up in the original ticket is that alex and happy that are installed by cabal but not visible in the run time PATH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 17:57:34 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 17:57:34 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.000d30788274366f0c78789a64f8501d@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Yet another possibility might be to do new-exec instead of new-run to run hadrian after it is built by cabal. As hvr's example commands show alex and happy are available in PATH then. I actually thougth that `new-run` is the same as `new-exec` in this respect, so I expected that both Alex and Happy will be visible to Hadrian's `loopkupInPath`. Same for running Hadrian with Stack. Could you check if it works when using the current `build.cabal.sh`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 18:14:49 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 18:14:49 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.90b7fd3d98f9e3c949fbdaa2fac467f2@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): In hadrian subdirectory: {{{ % which alex /Users/adam/.cabal/bin/alex % cabal new-exec which alex /Users/adam/.cabal/store/ghc-8.4.2/lx-3.2.4-ea33d38f/bin/alex }}} Running hadrian: {{{ % ./hadrian/build.cabal.sh -c -- ... user interrupt % grep AlexCmd config.log AlexCmd='/Users/adam/.cabal/bin/alex' }}} So new-run and new-exec does not have the same behaviour with the PATH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 19:29:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 19:29:13 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.c7b082ad400d25fd92ec7acc44a1df71@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Many thanks for checking @adamse! To me the difference in PATH settings between `new-run` and `new-exec` is surprising. Do you know about the rationale for this? If not, perhaps @hvr could clarify? I'm not suggesting to change anything, but merely want to learn a bit more about Cabal. Does switching from `new-run` to `new-exec` come with any disadvantages? I guess `new-exec` requires us to specify the path to the Hadrian executable which may be annoying. Is there anything else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 19:29:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 19:29:43 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.3d08c4287b0b1cb52e8477373dd171d2@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: alpmestan, hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 19:37:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 19:37:40 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.6db5077181140a815c0ce78302e3867d@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): No need to specify the full path to hadrian, this diff suffices: {{{ diff --git a/hadrian/build.cabal.sh b/hadrian/build.cabal.sh index 9fddd61c4e..3f45272345 100755 --- a/hadrian/build.cabal.sh +++ b/hadrian/build.cabal.sh @@ -24,7 +24,7 @@ CABVER=( ${CABVERSTR//./ } ) if [ "${CABVER[0]}" -gt 2 -o "${CABVER[0]}" -eq 2 -a "${CABVER[1]}" -ge 2 ]; then "$CABAL" --project-file="$PROJ" new-build $CABFLAGS -j exe:hadrian - "$CABAL" --project-file="$PROJ" new-run $CABFLAGS exe:hadrian -- \ + "$CABAL" --project-file="$PROJ" new-exec $CABFLAGS hadrian -- \ --lint \ --directory "$PWD" \ "$@" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 19:57:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 19:57:00 -0000 Subject: [GHC] #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc In-Reply-To: <048.1114bd71ff6c08fce3ce4e70e0b03476@haskell.org> References: <048.1114bd71ff6c08fce3ce4e70e0b03476@haskell.org> Message-ID: <063.275f440651dbaf899188629b8e0bdf77@haskell.org> #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): This is gonna be easily fixable once Hi Haddock lands. See https://github.com/haskell/haddock/pull/941 in particular. There's going to be a module-level Haddock option for controlling whether levity polymorphic signatures in that module get defaulted or not. If we want `throw :: Exception e => e -> a`, we'll have to add `{-# OPTIONS_HADDOCK print-runtime-reps #-}` to the top of `Control.Exception.Base`. Personally, I'd lean towards leaving the `throw`'s levity polymorphic signature in `Control.Exception.Base` and defaulting the re-export in `Control.Exception`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 19:57:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 19:57:16 -0000 Subject: [GHC] #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc In-Reply-To: <048.1114bd71ff6c08fce3ce4e70e0b03476@haskell.org> References: <048.1114bd71ff6c08fce3ce4e70e0b03476@haskell.org> Message-ID: <063.4036942d2ad3e174fd7e104c0e516860@haskell.org> #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 20:56:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 20:56:01 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.1dbd5593a4aa5ce339ceadd9a9834647@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Sounds great! If there are indeed no disadvantages then I think we should go ahead with this change. Do I understand correctly that this change is sufficient for the `configure` step to go through smoothly, because it can now see all required tools? Or do we also need to change the way we invoke the `configure` script from Hadrian? Another question: can/should we do the same change in the Stack build script? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 21:12:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 21:12:05 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.1f2d0f10ef95129355d823e9d0c70f48@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): This change is enough for the configure script to find alex & happy. I do not know if stack has support for installing build tools, so I cannot comment on that part. Gitlab MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/69 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 2 22:56:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Jan 2019 22:56:35 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.7404c99726eedf99f78fd0055c5d210e@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): @mayac may better remember these details than I. I tend to agree that the original program should be accepted, but perhaps there was a reason not to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 05:42:26 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 05:42:26 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` Message-ID: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this simple code: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-simpl -ddump-to-file -ddump-rule-firings #-} module C (f, g) where import Data.Int (Int64) f :: Double -> Int64 f = round g :: Double -> Int64 g = fromIntegral @Int @Int64 . round }}} There is a rule in {{{GHC.Int}}} that should translate {{{f}}} into {{{g}}} {{{#!hs "round/Double->Int64" round = (fromIntegral :: Int -> Int64) . (round :: Double -> Int) }}} If I compile the above module, I see {{{ Rule fired: round/Double->Int64 (GHC.Int) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: round/Double->Int (GHC.Float) }}} however in Core the functions end up different: {{{g}}} has an extra dictionary passed around: {{{#!hs -- RHS size: {terms: 11, types: 6, coercions: 0, joins: 0/0} f :: Double -> Int64 [GblId, Arity=1, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_a1sG [Occ=Once!] :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u [Occ=Once] -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr [Occ=Once] -> GHC.Int.I64# x#_a1Rr } }}] f = \ (x_a1sG :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr -> GHC.Int.I64# x#_a1Rr } } -- RHS size: {terms: 12, types: 14, coercions: 0, joins: 0/0} g :: Double -> Int64 [GblId, Arity=1, Caf=NoCafRefs, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_X1sX [Occ=Once!] :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C [Occ=Once] -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# _ [Occ=Dead], ds3_a28H [Occ=Once] #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } }}] g = \ (x_X1sX :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# ds2_a28G, ds3_a28H #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } } }}} This makes it over an order of magnitude slower than what it should be! {{{ benchmarked f time 111.1 ns (109.1 ns .. 113.9 ns) 0.997 R² (0.996 R² .. 0.998 R²) mean 111.1 ns (110.4 ns .. 112.0 ns) std dev 2.724 ns (2.195 ns .. 3.271 ns) benchmarked g time 7.160 ns (7.104 ns .. 7.224 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 7.196 ns (7.171 ns .. 7.231 ns) std dev 100.5 ps (71.97 ps .. 153.8 ps) }}} I don't know why the dictionary is present in {{{f}}} but not in {{{g}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 05:48:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 05:48:54 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.5a13d366212c473f2d90670e34a3cbc9@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): It seems the problem is that we only fire the {{{round/Double->Int64}}} rule and then for some reason we don't subsequently fire {{{round/Double->Int}}} rule. I don't know why that is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 05:49:10 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 05:49:10 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.1ead7142855c8dd8eaff9162501d290e@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Fuuzetsu: Old description: > Consider this simple code: > > {{{#!hs > {-# LANGUAGE TypeApplications #-} > {-# OPTIONS_GHC -ddump-simpl -ddump-to-file -ddump-rule-firings #-} > module C (f, g) where > > import Data.Int (Int64) > > f :: Double -> Int64 > f = round > > g :: Double -> Int64 > g = fromIntegral @Int @Int64 . round > }}} > > There is a rule in {{{GHC.Int}}} that should translate {{{f}}} into > {{{g}}} > > {{{#!hs > "round/Double->Int64" > round = (fromIntegral :: Int -> Int64) . (round :: Double -> Int) > }}} > > If I compile the above module, I see > > {{{ > Rule fired: round/Double->Int64 (GHC.Int) > Rule fired: fromIntegral/a->Int64 (GHC.Int) > Rule fired: fromIntegral/Int->Int (GHC.Real) > Rule fired: fromIntegral/a->Int64 (GHC.Int) > Rule fired: fromIntegral/Int->Int (GHC.Real) > Rule fired: round/Double->Int (GHC.Float) > }}} > > however in Core the functions end up different: {{{g}}} has an extra > dictionary passed around: > > {{{#!hs > -- RHS size: {terms: 11, types: 6, coercions: 0, joins: 0/0} > f :: Double -> Int64 > [GblId, > Arity=1, > Str=m, > Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) > Tmpl= \ (x_a1sG [Occ=Once!] :: Double) -> > case x_a1sG of { GHC.Types.D# ww1_a28u [Occ=Once] -> > case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt > ww1_a28u of > { GHC.Types.I# x#_a1Rr [Occ=Once] -> > GHC.Int.I64# x#_a1Rr > } > }}] > f = \ (x_a1sG :: Double) -> > case x_a1sG of { GHC.Types.D# ww1_a28u -> > case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of > { GHC.Types.I# x#_a1Rr -> > GHC.Int.I64# x#_a1Rr > } > } > > -- RHS size: {terms: 12, types: 14, coercions: 0, joins: 0/0} > g :: Double -> Int64 > [GblId, > Arity=1, > Caf=NoCafRefs, > Str=m, > Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) > Tmpl= \ (x_X1sX [Occ=Once!] :: Double) -> > case x_X1sX of { GHC.Types.D# ds1_a28C [Occ=Once] -> > case {__pkg_ccall base-4.12.0.0 Double# > -> State# RealWorld -> (# State# RealWorld, > Double# #)}_a28B > ds1_a28C GHC.Prim.realWorld# > of > { (# _ [Occ=Dead], ds3_a28H [Occ=Once] #) -> > GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) > } > }}] > g = \ (x_X1sX :: Double) -> > case x_X1sX of { GHC.Types.D# ds1_a28C -> > case {__pkg_ccall base-4.12.0.0 Double# > -> State# RealWorld -> (# State# RealWorld, > Double# #)}_a28B > ds1_a28C GHC.Prim.realWorld# > of > { (# ds2_a28G, ds3_a28H #) -> > GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) > } > } > }}} > > This makes it over an order of magnitude slower than what it should be! > > {{{ > benchmarked f > time 111.1 ns (109.1 ns .. 113.9 ns) > 0.997 R² (0.996 R² .. 0.998 R²) > mean 111.1 ns (110.4 ns .. 112.0 ns) > std dev 2.724 ns (2.195 ns .. 3.271 ns) > > benchmarked g > time 7.160 ns (7.104 ns .. 7.224 ns) > 1.000 R² (0.999 R² .. 1.000 R²) > mean 7.196 ns (7.171 ns .. 7.231 ns) > std dev 100.5 ps (71.97 ps .. 153.8 ps) > }}} > > I don't know why the dictionary is present in {{{f}}} but not in {{{g}}}. New description: Consider this simple code: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-simpl -ddump-to-file -ddump-rule-firings #-} module C (f, g) where import Data.Int (Int64) f :: Double -> Int64 f = round g :: Double -> Int64 g = fromIntegral @Int @Int64 . round }}} There is a rule in {{{GHC.Int}}} that should translate {{{f}}} into {{{g}}} {{{#!hs "round/Double->Int64" round = (fromIntegral :: Int -> Int64) . (round :: Double -> Int) }}} If I compile the above module, I see {{{ Rule fired: round/Double->Int64 (GHC.Int) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: fromIntegral/a->Int64 (GHC.Int) Rule fired: fromIntegral/Int->Int (GHC.Real) Rule fired: round/Double->Int (GHC.Float) }}} however in Core the functions end up different: {{{f}}} has an extra dictionary passed around: {{{#!hs -- RHS size: {terms: 11, types: 6, coercions: 0, joins: 0/0} f :: Double -> Int64 [GblId, Arity=1, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_a1sG [Occ=Once!] :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u [Occ=Once] -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr [Occ=Once] -> GHC.Int.I64# x#_a1Rr } }}] f = \ (x_a1sG :: Double) -> case x_a1sG of { GHC.Types.D# ww1_a28u -> case GHC.Float.$w$cround @ Int GHC.Real.$fIntegralInt ww1_a28u of { GHC.Types.I# x#_a1Rr -> GHC.Int.I64# x#_a1Rr } } -- RHS size: {terms: 12, types: 14, coercions: 0, joins: 0/0} g :: Double -> Int64 [GblId, Arity=1, Caf=NoCafRefs, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_X1sX [Occ=Once!] :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C [Occ=Once] -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# _ [Occ=Dead], ds3_a28H [Occ=Once] #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } }}] g = \ (x_X1sX :: Double) -> case x_X1sX of { GHC.Types.D# ds1_a28C -> case {__pkg_ccall base-4.12.0.0 Double# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a28B ds1_a28C GHC.Prim.realWorld# of { (# ds2_a28G, ds3_a28H #) -> GHC.Int.I64# (GHC.Prim.double2Int# ds3_a28H) } } }}} This makes it over an order of magnitude slower than what it should be! {{{ benchmarked f time 111.1 ns (109.1 ns .. 113.9 ns) 0.997 R² (0.996 R² .. 0.998 R²) mean 111.1 ns (110.4 ns .. 112.0 ns) std dev 2.724 ns (2.195 ns .. 3.271 ns) benchmarked g time 7.160 ns (7.104 ns .. 7.224 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 7.196 ns (7.171 ns .. 7.231 ns) std dev 100.5 ps (71.97 ps .. 153.8 ps) }}} I don't know why the dictionary is present in {{{f}}} but not in {{{g}}}. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 07:42:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 07:42:57 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.8cb243de9eadf44dd7f11ab6e2587986@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T13839 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5449 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @osa1 No Problem! I‘ll move the Patch to Gitlab next week, after my ski holidays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 11:48:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 11:48:23 -0000 Subject: [GHC] #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes In-Reply-To: <047.252f036686da3cb5c2c5a5709f59083c@haskell.org> References: <047.252f036686da3cb5c2c5a5709f59083c@haskell.org> Message-ID: <062.2c5e1a70faba45ca334145303fd32192@haskell.org> #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): To refresh my brain (and so I don't have to re-load this into my brain over and over)... as per above, but with annotation: 1. In `ghc/Main.hs`, the `main` function is the entry point for all of GHC. 1. The line with `(mode, argv3, flagWarnings) <- parseModeFlags argv2` parses the mode flags out. There are two possible cases here: either we have a `Left preStartupMode` or `Right postStartupMode`. The `preStartupMode` case is only for doing things before GHC starts up; things such as outputting the version number, etc (ie not executing code). So, we're only interested in the `Right postStartupMode` variant. 1. Continuing on, we start `GHC` by using `GHC.runGhc` with `mbMinusB`, then pull the flags out with `GHC.getSessionDynFlags`. We then `case` on `postStartupMode` which itself is an `Either` as well... it's similar to above, but here we have some `preLoadMode` values that (I'm assuming) can only be got when `GHC` has started up. Things like showing info, ghc usage, ghci usage and printing the flags. Here, though, we're only interested in the `Right` variant again — the `postLoadMode` value gets pattern matched out and; 1. next this hits the `main'` function as: `main' postLoadMode dflags argv3 flagWarnings`. This function then cases on `postLoadMode`... and the only branches of this we're really interested in is `DoInteractive -> (CompManager, HscInterpreted, LinkInMemory)` and `DoEval _ -> (CompManager, HscInterpreted, LinkInMemory)`... there are five other matches, but they're make, backpack, something called MkDependHS and also AbiHash, then the catchall (ie `_`). Essentially we want to block optimisation on the interactive and eval cases. So, this matches `(mode, lang, link)` to the values `(CompManager, HscInterpreted, linkInMemory)` respectively for both of these cases (interactive and eval). 1. Next we use a series of `let` expressions building up dflags1, dflags2, dflags3, etc. then, at the very end, we have another case stateament inside of an evaluation of `handleSourceError` to handle source code errors... again, the only two cases we care about are `DoInteractive` and `DoEval exprs`, both of which evalute to `ghciUI` expressions. Respectively: `ghciUI hsc_env dflags6 srcs Nothing` and `ghciUI hsc_env dflags6 srcs $ Just $ reverse exprs`. 1. The `ghciUI` function pulls the flags out after initializing the plugins with the `hsc_env` and `dflags0`, then sets this into the session with `GHC.setSessionDynFlags`. We then call the `interactiveUI` function with args thusly: `interactiveUI defaultGhciSettings srcs maybe_expr`. This function comes from the `GHCi.UI` module in `ghc/GHCi/UI.hs`. So, we want to investigate `interactiveUI` in `ghc/GHCi/UI.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 14:09:08 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 14:09:08 -0000 Subject: [GHC] #14797: High-residency modules during GHC build In-Reply-To: <047.916b3a5a2bf47612a2c2ec6726c0a648@haskell.org> References: <047.916b3a5a2bf47612a2c2ec6726c0a648@haskell.org> Message-ID: <062.7bde5f3b191fe21616f5f1c0c8b0c6cf@haskell.org> #14797: High-residency modules during GHC build -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is there any plan to work on this? It seems to me that the only productive way forward is to develop the profiling tooling so that memory usage can be analysed in a systematic way rather than ad-hoc way with the current profiling tools. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 18:16:13 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 18:16:13 -0000 Subject: [GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint Message-ID: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> #16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While experimenting with quantified constraints, I find I need to explicitly specify a quantified constraint in an instance declaration that I think should be deduced automatically. When I leave it out, GHC complains that it cannot deduce {{{Num (f a)}}} in the code below. The full source code is attached. The relevant lines are {{{ instance ( Functor f, Dom f ~ NFun, Cod f ~ NFun , forall a. Ok NFun a => Num a -- I don't want to write this constraint ) => Functor (NIdF f) where type Dom (NIdF f) = Dom f type Cod (NIdF f) = Cod f fmap f = NFun \(NIdF xs) -> NIdF (neval (fmap f) xs) }}} where the line marked "I don't want to write ..." points to the constraint I don't want to have to write manually. The definition of the {{{NFun}}} is {{{ instance Category NFun where type Ok NFun a = Num a id = NFun P.id NFun g . NFun f = NFun (g P.. f) }}} Note that the constraint in question does not involve the type {{{NIdF}}} for which the instance is declared – it is a generic condition that is always true, given the instance declaration of {{{NFun}}} (see the definition of {{{Ok}}} there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 18:16:48 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 18:16:48 -0000 Subject: [GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint In-Reply-To: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> References: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> Message-ID: <062.96728b5119f0d325af03d8a587de71b4@haskell.org> #16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by eschnett): * Attachment "CatQC.hs" added. Source code demonstrating the issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 19:09:01 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 19:09:01 -0000 Subject: [GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint In-Reply-To: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> References: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> Message-ID: <062.926a34edc8985b4ac5acd78f8ad304ca@haskell.org> #16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14680 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14680 Comment: I'm afraid what you are trying to write just won't work (at least, not today). This quantified constraint: {{{#!hs forall a. Ok (Dom f) a => Ok (Cod f) (f a) }}} Uses a type family in the head of the constraint, which GHC doesn't support. (See [https://ghc.haskell.org/trac/ghc/ticket/14860 this Trac ticket].) The fact that GHC 8.6 somehow accepts this as a superclass constraint for `Functor` is a bug, and as you've discovered, GHC won't actually use that constraint in any instances. On GHC HEAD, your (unmodified) code is rejected with an error message: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling CatQC ( Bug.hs, Bug.o ) Bug.hs:32:1: error: • Quantified predicate must have a class or type variable head: forall (a :: ObjKind). Ok (Dom f) a => Ok (Cod f) (f a) • In the quantified constraint ‘forall (a :: ObjKind). Ok (Dom f) a => Ok (Cod f) (f a)’ In the context: (Category (Dom f), Category (Cod f), forall (a :: ObjKind). Ok (Dom f) a => Ok (Cod f) (f a)) While checking the super-classes of class ‘Functor’ In the class declaration for ‘Functor’ | 32 | class ( Category (Dom f), Category (Cod f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} There is a workaround (described in https://ghc.haskell.org/trac/ghc/ticket/14860#comment:19) that can sometimes be used. Unfortunately, this workaround doesn't work here, because you're trying to use a quantified constraint in a superclass position. #14860 is tracking this infelicity already, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 19:10:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 19:10:16 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.83328a27375b31917082e3c87d26cad0@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #16123 Comment: See #16123 for an example of a program which cannot work without the flattener receiving the upgrade described in comment:19. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 19:54:00 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 19:54:00 -0000 Subject: [GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint In-Reply-To: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> References: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> Message-ID: <062.4e3f3b8a14240038803d1ecd965046df@haskell.org> #16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14680 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by eschnett): For the record: I have a working work-around using {{{Data.Constraint}}}. The {{{functor}}} class then reads {{{ -- | A functor class (Category (Dom f), Category (Cod f)) => Functor f where -- | Prove that this functor maps from its domain to its codomain proveFunctor :: Ok (Dom f) a => Ok (Dom f) a :- Ok (Cod f) (f a) type Dom f :: CatKind type Cod f :: CatKind fmap :: (Ok (Dom f) a, Ok (Dom f) b) => Dom f a b -> Cod f (f a) (f b) }}} and the previously-failing instance declaration becomes {{{ instance (Functor f, Dom f ~ NFun, Cod f ~ NFun) => Functor (NIdF f) where type Dom (NIdF f) = Dom f type Cod (NIdF f) = Cod f proveFunctor :: forall a. Ok (Dom (NIdF f)) a => Ok (Dom (NIdF f)) a :- Ok (Cod (NIdF f)) ((NIdF f) a) proveFunctor = Sub Dict \\ (proveFunctor @f :: Ok (Dom f) a :- Ok (Cod f) (f a)) fmap f = NFun \(NIdF xs) -> NIdF (neval (fmap f) xs) }}} The disadvantage is that {{{proveFunctor}}} is now an explicit function, and using {{{fmap}}} now might require calling {{{proveFunctor}}} explicitly to invoke it as proof. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 23:22:20 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 23:22:20 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.1c9f96bd6fb93e47fdd8a1f4a39d91a9@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): a `git grep 'go (App '` might uncover more places where we could consider recognising `noinline`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 3 23:54:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Jan 2019 23:54:27 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.4348997a6d031432c2091063c3d95bf8@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): I have a merge request: https://gitlab.haskell.org/ghc/ghc/merge_requests/10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 05:38:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 05:38:42 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.3345f3509599a209dfef73fb519bc56d@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: In the interface file for GHC.Int I see: {{{ "round/Double->Int64" forall ($dRealFrac :: GHC.Real.RealFrac GHC.Types.Double) ($dIntegral :: GHC.Real.Integral Int64) GHC.Real.round @ GHC.Types.Double $dRealFrac @ Int64 $dIntegral = GHC.Base.. @ GHC.Types.Int @ Int64 @ GHC.Types.Double (GHC.Real.fromIntegral @ GHC.Types.Int @ Int64 GHC.Real.$fIntegralInt $fNumInt64) (GHC.Float.$fRealFracDouble_$cround @ GHC.Types.Int GHC.Real.$fIntegralInt) }}} So the RHS of the RULE already contains the bad code. This appears to be caused by the fact that the RHS of a rule is rewritten with GHC's built-in rules, even when there is a conflicting user-defined one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 05:42:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 05:42:51 -0000 Subject: [GHC] #16124: prof_hc_hb way failures on CI Message-ID: <043.5fc615f1a25c7b6b61bc6fcb0cc4fc4f@haskell.org> #16124: prof_hc_hb way failures on CI -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reported by Gabor in https://gitlab.haskell.org/ghc/ghc/merge_requests/67#note_1845 It seems like we have non-deterministic `prof_hc_hb` problems that are caught by the CI sometimes: - https://gitlab.haskell.org/adamse/ghc/-/jobs/8518 - https://gitlab.haskell.org/ghc/ghc/-/jobs/8489 Another ticket for profiling build problems: #15508. I fixed a few bugs in that ticket, but there are at least two more bugs to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 09:25:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 09:25:29 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.0e92fe081ef0ab5d49a4508577fb7157@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here is what is happening * There is a built-in rule for `round` that rewrites `round (RFDict _ _ r _ _) = r`; that is, `round` applied to a suitable dictionary just selects the method. * Currently, built-in rules are always active; they can't be delayed to a later phase. This could be changed relatively easily, but that's the way it is right now. * Rules are applied to the RHS of other rules, if the phases allow; this seems reasonable. After all, that's what will happen whenever the rule is applied. * In particular, the built-in rule is applied to the RHS of the rule in `GHC.Int`, as comment:3 says. * I think the reason things go wrong is that in the RHS of hte rule in `GHC.Int` you really want to apply the rule `"round/Double->Int"` in `GHC.Float`, but perhaps it is not imported by `GHC.Int`? Anyway, probably the best solution here is to rewrite the rule in `GHC.Int` to {{{ "round/Double->Int64" round = (fromIntegral :: Int -> Int64) . GHC.Float.roundDoubleInt }}} (And maybe the same for `fromIntegral`?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 09:39:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 09:39:25 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.931528cabcc545eb9ea8e19dade91f13@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by osa1): More unreg validate failures at: https://gitlab.haskell.org/mpickering/ghc/pipelines/675 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 10:17:22 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 10:17:22 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.37d2b93a017bc0f3fa1e1b68ec681952@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > `exprIsCheapX` helped a lot What does that mean? How did it help? Rather than doing this deep pattern matching during `exprIsCheapX` (which will happen repeatedly in an `App`-chain), I think it might be nicer (more efficient) to accumulate a list of (value) arguments instead of the `n` argument to `go`. > Check out exprIsBig too. Maybe. But concentrate on the places where we know it makes a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 10:46:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 10:46:20 -0000 Subject: [GHC] #15877: --flavour=quick followed by --flavour=prof fails In-Reply-To: <049.2c7f5c96cfaf8ffe2a60dc4dc965d33c@haskell.org> References: <049.2c7f5c96cfaf8ffe2a60dc4dc965d33c@haskell.org> Message-ID: <064.738aebeb28d7f9692d423763c62140fd@haskell.org> #15877: --flavour=quick followed by --flavour=prof fails -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: closed => new * resolution: fixed => Comment: It happened to me with current head. {{{ ./hadrian/build.stack.sh -c -j binary-dist WARNING: Ignoring out of range dependency (allow-newer enabled): Cabal-2.5.0.0. happy requires: <2.4 hadrian-0.1.0.0: build (exe) hadrian-0.1.0.0: copy/register Log files have been written to: snip.../hadrian/.stack-work/logs/ snip.../_build/stage1/rts/build/libCffi_p.a: copyFile: does not exist (No such file or directory) }}} A workaround is to delete libffi.a: {{{ rm _build/stage1/libffi/build/inst/lib/libffi.a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 11:44:19 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 11:44:19 -0000 Subject: [GHC] #16062: Improve -dynamic-too progress messages In-Reply-To: <043.ad5c23976dc1e7038ab1cdfb3d5c0b5c@haskell.org> References: <043.ad5c23976dc1e7038ab1cdfb3d5c0b5c@haskell.org> Message-ID: <058.5400d10fb7ace2add1e0b773a6ab8b27@haskell.org> #16062: Improve -dynamic-too progress messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): Here are some notes: The list of files seems to be produced by {{{showModMsg}}} in main/HscTypes.hs. It uses {{{ModLocation{ml_obj_file} }}} to say which .o file we're compiling. There is no corresponding {{{ml_dyn_obj_file}}} but the name could perhaps be reconstructed using ml_obj_file and {{{dynObjectSuf}}} from dflags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 11:59:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 11:59:27 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.1ac00798b10b958475b778349d3cda40@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): One of the remaining issues is this: sometimes with prof+threaded builds we increment info pointers. This either segfaults, or the GC thinks that the object is already evacuated (because info pointer looks like a forwarding pointer when we increment it) and chaos ensues. Here's an example, in this generated code for `GHC.Conc.Sync.childHandler`: {{{ Dump of assembler code for function base_GHCziConcziSync_childHandler1_info: 0x000000000051c5c8 <+0>: add $0x28,%r12 0x000000000051c5cc <+4>: cmp 0x358(%r13),%r12 0x000000000051c5d3 <+11>: ja 0x51c61a 0x000000000051c5d5 <+13>: mov 0x360(%r13),%rax => 0x000000000051c5dc <+20>: addq $0x3,0x48(%rax) 0x000000000051c5e1 <+25>: movq $0x51bd50,-0x20(%r12) 0x000000000051c5ea <+34>: mov 0x360(%r13),%rax 0x000000000051c5f1 <+41>: mov %rax,-0x18(%r12) 0x000000000051c5f6 <+46>: mov 0xd34988,%eax 0x000000000051c5fd <+53>: shl $0x1e,%rax 0x000000000051c601 <+57>: mov %rax,-0x10(%r12) 0x000000000051c606 <+62>: mov %r14,(%r12) 0x000000000051c60a <+66>: mov $0xb57742,%r14d 0x000000000051c610 <+72>: lea -0x20(%r12),%rbx 0x000000000051c615 <+77>: jmpq 0xa3c4d0 0x000000000051c61a <+82>: movq $0x28,0x388(%r13) 0x000000000051c625 <+93>: mov $0xb57770,%ebx 0x000000000051c62a <+98>: jmpq *-0x8(%r13) }}} The highlighted line increments this object's info pointer: {{{ >>> print *(StgClosure*)0x4207528048 $34 = { header = { info = 0x9f2200 , prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528060 } >>> call printClosure((StgClosure*)0x4207528048) ghc-prim:GHC.Types.:(0x42075280b9, 0x4207528092) }}} After that line: {{{ >>> print *(StgClosure*)0x4207528048 $40 = { header = { info = 0x9f2203 , prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528060 } }}} This is not a valid closure anymore. I don't know what that code is supposed to increment. I'll try to generate Cmm for `GHC.Conc.Sync.childHandler` and see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 12:08:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 12:08:10 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.d6ef566bee200a8ba347b3f2beb61b72@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): Looking at the assembly again, this line {{{ 0x000000000051c5cc <+4>: cmp 0x358(%r13),%r12 }}} does heap limit check for allocation (`%r12` is the reg table, 0x358 = 856, offset for `rHpLim`), then this line {{{ 0x000000000051c5d5 <+13>: mov 0x360(%r13),%rax }}} Moves `rCCCS` (current cost centre stack) to `%rax`, so this line {{{ 0x000000000051c5dc <+20>: addq $0x3,0x48(%rax) }}} Tries to increment current cost centre stack's `mem_alloc`! Somehow `rCCCS->mem_alloc` is actually info pointer of another closure! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 12:26:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 12:26:13 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.fc9ea7f4a368c63cbfa730a9cc97df0f@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): Here's where we break the `rCCCS` register: {{{ Thread 2 hit Hardware watchpoint 4: ((StgRegTable*)0xd35718)->rCCCS Old value = (struct CostCentreStack_ *) 0x4207528000 New value = (struct CostCentreStack_ *) 0xd2df60 0x0000000000a376f8 in stg_returnToStackTop () >>> bt #0 0x0000000000a376f8 in stg_returnToStackTop () #1 0x0000000000000000 in ?? () >>> call printClosure(0x4207528000) ghc-prim:GHC.Types.:(0x4207528071, 0x420752804a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 12:58:09 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 12:58:09 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.b122c0fae2b875af51a8bdf99c82887d@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): Looking at the assembly for `returnToStackTop`, we're loading a TSO's `prof` field to `rCCCS` so the problem is with the `prof` field of a TSO. Debugging further, here's where we first update `prof` field of a TSO with the problematic value (0x4207528000): {{{ Thread 2 hit Hardware watchpoint 6: ((StgTSO *) 0x420019d7e0)->prof.cccs Old value = (CostCentreStack *) 0x4207528000 New value = (CostCentreStack *) 0xb44390 0x0000000000a37819 in stg_returnToSched () >>> bt #0 0x0000000000a37819 in stg_returnToSched () #1 0x0000000000000000 in ?? () >>> print *(CostCentreStack *)0xb44390 $60 = { ccsID = 241, cc = 0xb44350, prevStack = 0xd2df00 , indexTable = 0x0, root = 0xb44390, depth = 1, scc_count = 0, selected = 1, time_ticks = 0, mem_alloc = 59522365, inherited_alloc = 0, inherited_ticks = 0 } }}} (Note that this is reverse executions so "old" is actually new) Interestingly at this point 0x4207528000 actually looks like a valid cost centre stack: {{{ >>> print *(CostCentreStack *)0x4207528000 $62 = { ccsID = 283607809913, cc = 0xb44390, prevStack = 0x5, indexTable = 0x4207528071, root = 0x420752804a, depth = 283607809953, scc_count = 11813776, selected = 4, time_ticks = 0, mem_alloc = 283607809985, inherited_alloc = 11813776, inherited_ticks = 5 } >>> print *((CostCentreStack *)0x4207528000)->cc $64 = { ccID = 241, label = 0xb44350 "\a", module = 0xd2df00 "|", srcloc = 0x0, mem_alloc = 11813776, time_ticks = 1, is_caf = 0, link = 0x1 } }}} So currently we don't have a problem. If I continue: {{{ Thread 2 hit Hardware watchpoint 8: ((StgTSO *) 0x420019d7e0)->prof.cccs Old value = (CostCentreStack *) 0xb44390 New value = (CostCentreStack *) 0x4207528000 0x0000000000a3d1c2 in stg_AP_STACK_info () >>> bt #0 0x0000000000a3d1c2 in stg_AP_STACK_info () #1 0x0000000000000000 in ?? () >>> print *(StgClosure*)0x4207528000 $69 = { header = { info = 0x9f2200 , prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528018 } }}} This is the second time we update the `TSO->prof` with the problematic value, and NOW things look bad. I don't understand how we can use the same location for a cost centre stack and a heap closure. As far as I know cost centre stacks are allocated in an arena, and are never freed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 13:09:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 13:09:41 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.87e6f111f1350363a59932c26412bc79@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:10 simonpj]: > > `exprIsCheapX` helped a lot > > What does that mean? How did it help? There seem to be two distinct mechanisms to float out expressions to toplevel. After fixing `notWorthFloating` and `exprIsTrivial` (which took care of the float-out pass) still a bunch of expressions (e.g `noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo`) that are destined for class dictionaries got floated out for no reason. After fixing `exprIsCheapX` this is not happening any more. > > Rather than doing this deep pattern matching during `exprIsCheapX` (which will happen repeatedly in an `App`-chain), I think it might be nicer (more efficient) to accumulate a list of (value) arguments instead of the `n` argument to `go`. > > > Check out exprIsBig too. > > Maybe. But concentrate on the places where we know it makes a difference. Sounds like a plan. I'll wrap up the changes that I have so far and work on more testcases. I think that it'll be okay to land this for 8.10. If you want to look at my changes, you'll find them in https://gitlab.haskell.org/ghc/ghc/commits/wip/T16039 . Then I'll scrutinise the code for similar problems in a low-prio follow-up ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 13:44:40 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 13:44:40 -0000 Subject: [GHC] #16125: Broken Links in docs/users_guide/using-optimisation.rst Message-ID: <048.36371066852869c274db7532d64c9728@haskell.org> #16125: Broken Links in docs/users_guide/using-optimisation.rst -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1574 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Chapter 7 of `Andre Santos's PhD thesis `__ }}} Following this link leads to a 404 not found. I think the correct one should be: https://www.microsoft.com/en-us/research/publication /compilation-transformation-non-strict-functional-languages/ ----- {{{ implementation is described in the paper `Theory and Practice of Demand Analysis in Haskell``__. }}} This one contains one ` too much. The rendered link points to the document (using-optimisation.html) itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 13:45:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 13:45:13 -0000 Subject: [GHC] #16125: Broken Links in docs/users_guide/using-optimisation.rst In-Reply-To: <048.36371066852869c274db7532d64c9728@haskell.org> References: <048.36371066852869c274db7532d64c9728@haskell.org> Message-ID: <063.4ae02122b6d69a60aad6869ff7f2665e@haskell.org> #16125: Broken Links in docs/users_guide/using-optimisation.rst -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1574 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 13:49:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 13:49:02 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.704a342efe5489c4389642c8fa209ba4@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9269 | Blocking: Related Tickets: #12612, #13901, | Differential Rev(s): #15942 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We think that implementing #12088, comment:37 will nail this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 14:03:55 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 14:03:55 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.24f929358c67d6a17c073a2039919c8b@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Current error message is a bit better ``` T12564.hs:18:3: error: • Illegal type synonym family application ‘Len @a _1’ in instance: At @a ((':) @a x _1) ('FZ @(Len @a _1)) • In the equations for closed type family ‘At’ In the type family declaration for ‘At’ | 18 | At (x ': _) FZ = x | ^^^^^^^^^^^^^^^^^^ ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 14:05:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 14:05:21 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.02aa542f8d45fa11480acb97e87d473e@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer Comment: Would be very useful to implement this and there is a clear implementation plan indicated by Ian in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 15:00:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 15:00:05 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.7da4fc1c5c584ad2dd1f0f73cccb606a@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have an approach here worth documenting. In brief: flatten equations' left-hand sides, emitting constraints during reduction. Here is how the example in the OP would work. Original equation: {{{#!hs At (x ': _) FZ = x }}} with implicit things made explicit: {{{#!hs At @a ((:) @a x _1) (FZ @(Len @a _1)) = x }}} But now, we ''flatten''. By this, I mean we take all type family applications on the LHS and convert them into variables, and assert equality constraints that the variables equal the original type family applications. To wit: {{{#!hs (m ~ Len @a _1) => At @a ((:) @a x _1) (FZ @m) = x }}} This yields a ''constrained'' type family equation. (Note: this is mostly unrelated to [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1075&context=compsci_pubs Constrained Type Families]) During reduction, this equation would match a target regardless of the (implicit) argument to `FZ`, but the matcher would then emit a constraint asserting that this argument equals `Len @a _1`. It's quite like how class instance matching works: we match against the head, emitting any instance constraints. Type family equations give rise to axioms in Core. To keep type safety, we would need these axioms to take the evidence of the equality match as arguments. Continuing our example, we would get this axiom: {{{ axAt :: forall (a :: Type) (x :: a) (_1 :: [a]) (m :: Nat). forall (cv :: m ~ Len @a _1). At @a ((:) @a x _1) (FZ @m) ~ x }}} Note that there are two `forall`s: the first binds type variables and the second binds coercion variables. In this case, the coercion variable `cv` is unused in the RHS, but it might potentially be mentioned. This equation could be used to reduce `At ["a", "b", "c"] FZ` to `"a"`. We would use the instantiated axiom {{{ axAt Symbol "a" ["b", "c"] 2 coLen :: At ["a", "b", "c"] FZ ~ "a" }}} where `coLen :: 2 ~ Len ["b", "c"]` is built from the axioms that describe the behavior of `Len`. Note that there is already some infrastructure for this: the `cvs` in `CoAxBranch` (and a few other places nearby) are exactly these coercion variables. What's remaining to do is to perform the flattening pass that inserts the cvs and to teach the type-family reduction mechanism (in `TcFlatten`) to emit the constraints. One challenge is that sometimes (`normaliseType`) we reduce type families without the ability to solve constraints, so some care must be taken there. However, these cases are outside our usual pipeline and can be special-cased. (While implementing `-XTypeInType`, I did this once upon a time, so I know it's possible.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 15:21:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 15:21:28 -0000 Subject: [GHC] #16126: Make -threaded the default Message-ID: <049.6bccecc4e766ed4d66f82d70ee136719@haskell.org> #16126: Make -threaded the default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon M writes back in 2016 > Related to this, I think it's about time we made -threaded the default. We could add a -single-threaded option to get back the old behaviour. > > There is a small overhead to using -threaded, but -threaded is also required to make a lot of things work (e.g. waitForProcess in a multithreaded program, not to mention parallelism). All that needs doing is to add a flag `-single-threaded` to enable the old behaviour and a deprecation warning alerting uses that `-threaded` is the new default. https://mail.haskell.org/pipermail/ghc-devs/2016-October/013101.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 16:33:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 16:33:13 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.dcbd4a7024db577e1f76228b8bcf6726@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm getting a bit lost. * In ticket:15155#comment:11 we decided that we do NOT have the invariant that a strict constructor always has a correctly-tagged pointer in it. * An example of the difficulty is in ticket:15696#comment:36 * Simon Marlow suggested one way to restore the invariant in ticket:15155#comment:17. But we have not implemented this. So doing this IND_STATIC stuff might reduce code size a tiny bit, but will not (of itself) change the situation for tagged pointers in strict constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 16:56:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 16:56:33 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.e9474000d3c19adbbda5325864b08e7d@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Generally I like this. But: * We'd need to update the dynamic semantics and subject-reduction proof for FC to show that the resulting system is sound. * I'm very troubled by the fact that the evidence is not used. It's all very similar to class instances, except that in class instances we use the evidence. * You way that the "evidence may potentially be mentioned" but how might that happen? * In the example here we know for certain that the evidence is redundant. The `(Len @a _1)` was not written by the user; it was inferred. GHC never guesses, so it must be uniquely determined. So it's really a waste of time to construct and pass that evidence at every call site. Surely there must be a solid criterion for what components of the type are fully determined, and hence redundant and don't need to be matched? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 17:05:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 17:05:10 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.99f1b8d436dfeb17e9785603612f5a1c@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > The type checker currently maintains two invariants, documented in `Note > [The well-kinded type invariant]` in TcType and `Note [The tcType > invariant]` in TcHsType. These are a pain to maintain, and Simon and I > cooked up a plan not to. > > Step 1. The tcType invariant is all about `tcInferApps`, at least > according to the Note. Previously, we couldn't zonk in `tcInferApps`, > because types were knot-tied. But now we can! So, `tcInferApps` could > take the type only (not its kind), zonk it, then get the type's (zonked) > kind. This might also mean that `tc_infer_hs_type` no longer needs to > return a type/kind pair, but could just return a type. > > After this is done, we can likely remove all the zonks that are in > service to the tcType invariant, findable by a search. > > Step 2. The well-kinded type invariant is also about the need to zonk > sometimes. But, instead, we could just always zonk on-the-fly. That is, > we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as > they go. To make sure we're calling the right function at the right time, > we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're > forced to call monadic functions on `TcType`s. This will likely lead to > code duplication between `Type` and `TcType`, but we might be able to > banish `zonkTcType` (and its many friends) entirely. Also gone would be > the `naked` functions, which are all about maintaining the well-kinded > type invariant. This step would, as a side effect, fix #15799 and #15918, > which is about treating `TcType`s differently from `Type`s. > > '''Work in progress on `wip/T15952`''' New description: The type checker currently maintains two invariants, documented in `Note [The well-kinded type invariant]` in TcType and `Note [The tcType invariant]` in TcHsType. These are a pain to maintain, and Simon and I cooked up a plan not to. Step 1. The tcType invariant is all about `tcInferApps`, at least according to the Note. Previously, we couldn't zonk in `tcInferApps`, because types were knot-tied. But now we can! So, `tcInferApps` could take the type only (not its kind), zonk it, then get the type's (zonked) kind. This might also mean that `tc_infer_hs_type` no longer needs to return a type/kind pair, but could just return a type. After this is done, we can likely remove all the zonks that are in service to the tcType invariant, findable by a search. Step 2. The well-kinded type invariant is also about the need to zonk sometimes. But, instead, we could just always zonk on-the-fly. That is, we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as they go. To make sure we're calling the right function at the right time, we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're forced to call monadic functions on `TcType`s. This will likely lead to code duplication between `Type` and `TcType`, but we might be able to banish `zonkTcType` (and its many friends) entirely. Also gone would be the `naked` functions, which are all about maintaining the well-kinded type invariant. This step would, as a side effect, fix #15799 and #15918, which is about treating `TcType`s differently from `Type`s. '''Work in progress on `wip/T15952`''' '''Merge request at [https://gitlab.haskell.org/ghc/ghc/merge_requests/74]''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 17:14:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 17:14:06 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.20d59a4d69ae54b3949706eb16ae4320@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): We will probably not be able to restore the invariant for all cases. Here is a curious case {{{#!hs module A where newtype A = A Int num :: Int num = 42 {-# NOINLINE a #-} a = A num }}} {{{#!hs module Main where import A data T = MkT A t = MkT a }}} In the absence of your patch `MkT` gets passed an untagged pointer, because the unfolding of `a` is wrongly interpreted. GHC should be able to know that `a` has the `I#` constructor. **Your patch improves on the situation.** `MkT` now gets passed a tagged pointer. BUT: when the pointee `a` is an IND_STATIC closure (in the above case it is), we get incorrect behaviour, as the closure has the wrong layout and wants to be ''entered''. #15155 recovers correctness. I don't really care about the bang invariant. What I care is that GHC is not coerced into deliberately throwing away perfectly good hints (leading to suboptimal tagging) because of the IND_STATIC hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 17:18:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 17:18:24 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.072b0ad123205fc706ec419901cb5a6e@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > a bunch of expressions (e.g noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo) that are destined for class dictionaries got floated out for no reason. Interesting. Which pass did this? I suspect that we should have invariants like {{{ exprIsTrivial e implies notWorthFloating e exprIsTrivial e implies exprIsCheapX e }}} I wonder if these are true right now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 17:35:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 17:35:53 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.0c420efbd2e197d019d6e8e59d70a94b@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. So I think we now agree that the IND_STATIC patch is about (a) code size and (b) performance; and that both are very small (albeit worthwhile) improvements. ''It is not about correctness''. OK so far? When you say "your patch", what do you mean? When you say "incorrect behaviour" do you meant that we get a seg-fault? Or just that we enter a closure that could be properly tagged? To be concrete, suppose we have {{{ f x = case t of MkT (A a) -> case a of I# y -> (I# (y +# 1) + x main = print (map f [1..1000]) }}} In the code for the `case a` in `f`, we'll have a conditional that tests the tag-bits on `a`. If they are 00 we'll enter `a`; and ''this path must exist'' in case we put a thunk in `MkT`; indeed `MkT` is not even strict in this case. However, we'd prefer not to take that code path, so it'd be better to put a correctly-tagged pointer into the `MkT`. To do this we need your patch; and it must get exploited in two different places in the code generator. * When allocating a static closure, like in your example {{{ t = MkT a }}} * When allocating a dynamic closure, like this: {{{ data S = MkS Int A f x = ...(MkS x a)... }}} Here that `MkS x a` should get a correctly-tagged second field. It'd be good to ensure that you test both situations. Now it is much clearer. If you could reflect the clarity in the Note, that would be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 18:19:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 18:19:31 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.6285fcc409d4cfbb39697bb2d46326c5@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:30 simonpj]: > Great. So I think we now agree that the IND_STATIC patch is about (a) code size and (b) performance; and that both are very small (albeit worthwhile) improvements. ''It is not about correctness''. OK so far? Agree, we may have different definitions of "correct". No crashes. Yep. > > When you say "your patch", what do you mean? > This one: https://ghc.haskell.org/trac/ghc/attachment/ticket/14677/lf-imported-patch Applying this causes crashes. #15155 helps with that. #16039 helps more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 18:29:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 18:29:57 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.693930c7b16660ecbe8aca9c1834b2ed@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): * Bizarrely, I don't think we need to do much proving. The type safety proof depends on the non-overlap of axiom LHSs. That's unchanged here -- the overlap check must treat any type family application on an LHS just like it would a variable. The equality constraints serve only to reduce the applicability of axioms, never to increase it. Thus, no threats to safety. * But the evidence ''is'' used: it's passed to the coercion axiom. The evidence is the `coLen` in my example above. * I take back the "evidence may be mentioned" comment. * GHC passes loads of redundant information at every call site (e.g. `id @Bool True`). This is not new. The uniquely-determined check would help those other places too. I think, in the end, that idea is orthogonal to the plan here, which would work for `F x (G x) = True`, should we ever want to support that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 19:15:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 19:15:36 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.cd94c3d6f9ae667e3c82d5187cae3aba@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:12 simonpj]: > > a bunch of expressions (e.g noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo) that are destined for class dictionaries got floated out for no reason. > > Interesting. Which pass did this? Simplifier. But the mechanism by which it picks up the level variables is still a riddle for me. I'll research this, as I think things should be done in one place. > > I suspect that we should have invariants like > {{{ > exprIsTrivial e implies notWorthFloating e > exprIsTrivial e implies exprIsCheapX e > }}} > I wonder if these are true right now? Who knows. This is a nice use-case for `ASSERT()`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 19:26:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 19:26:24 -0000 Subject: [GHC] #16125: Broken Links in docs/users_guide/using-optimisation.rst In-Reply-To: <048.36371066852869c274db7532d64c9728@haskell.org> References: <048.36371066852869c274db7532d64c9728@haskell.org> Message-ID: <063.7a4c4c29cd4cb82242f6f58cad73ed64@haskell.org> #16125: Broken Links in docs/users_guide/using-optimisation.rst -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: bug | Status: patch Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1574 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: new => patch Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/75/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 20:50:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 20:50:23 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 Message-ID: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I apologize in advance for a non-minimised repro. The panic (with a small `-ddump-tc-trace` excerpt, but full log also attached): {{{ tcPolyExprNC Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcSkolemise tcInferId voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) tcCheckId voc_a4TB2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcWrapResult Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Expected: Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tc_sub_type_ds ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ty_expected = Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) deeply_instantiate final subst origin: arising from a use of ‘voc_a4TB2’ type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) subst: [TCvSubst In scope: InScope {i_a4TMf} Type env: [] Co env: []] u_tys tclvl 2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) arising from a type equality Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): piResultTys1 * [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro (requires Nix & some download time, provides hard repro guarantees in return): {{{ $ git clone https://github.com/deepfire/holotype $ cd holotype $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a $ nix-shell [nix-shell:~/holotype]$ make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 20:51:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 20:51:44 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.b98d9ed58880d88530717152fb42479c@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by _deepfire): * Attachment "ghc.out.xz" added. Repro output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 20:52:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 20:52:42 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.407658afd610809159439e5d648533e9@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by _deepfire: Old description: > I apologize in advance for a non-minimised repro. > > The panic (with a small `-ddump-tc-trace` excerpt, but full log also > attached): > > {{{ > tcPolyExprNC > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcSkolemise > tcInferId > voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > tcCheckId > voc_a4TB2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcWrapResult > Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Expected: Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tc_sub_type_ds > ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ty_expected = Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > deeply_instantiate final subst > origin: arising from a use of ‘voc_a4TB2’ > type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > subst: [TCvSubst > In scope: InScope {i_a4TMf} > Type env: [] > Co env: []] > u_tys > tclvl 2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > arising from a type equality Vocab > i_a4TMf[sk:1] (Present * * > i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] > i_a4TNv[tau:2]) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.1 for x86_64-unknown-linux): > piResultTys1 > * > [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Repro (requires Nix & some download time, provides hard repro guarantees > in return): > > {{{ > $ git clone https://github.com/deepfire/holotype > $ cd holotype > $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a > $ nix-shell > [nix-shell:~/holotype]$ make > }}} New description: I apologize in advance for a non-minimised repro. The panic (with a small `-ddump-tc-trace` excerpt, but full log also attached -- https://ghc.haskell.org/trac/ghc/attachment/ticket/16127/ghc.out.xz): {{{ tcPolyExprNC Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcSkolemise tcInferId voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) tcCheckId voc_a4TB2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcWrapResult Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Expected: Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tc_sub_type_ds ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ty_expected = Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) deeply_instantiate final subst origin: arising from a use of ‘voc_a4TB2’ type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) subst: [TCvSubst In scope: InScope {i_a4TMf} Type env: [] Co env: []] u_tys tclvl 2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) arising from a type equality Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): piResultTys1 * [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro (requires Nix & some download time, provides hard repro guarantees in return): {{{ $ git clone https://github.com/deepfire/holotype $ cd holotype $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a $ nix-shell [nix-shell:~/holotype]$ make }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 21:02:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 21:02:01 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.291880894e5c7808636631e1442853e8@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by _deepfire: Old description: > I apologize in advance for a non-minimised repro. > > The panic (with a small `-ddump-tc-trace` excerpt, but full log also > attached -- > https://ghc.haskell.org/trac/ghc/attachment/ticket/16127/ghc.out.xz): > > {{{ > tcPolyExprNC > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcSkolemise > tcInferId > voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > tcCheckId > voc_a4TB2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcWrapResult > Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Expected: Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tc_sub_type_ds > ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ty_expected = Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > deeply_instantiate final subst > origin: arising from a use of ‘voc_a4TB2’ > type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > subst: [TCvSubst > In scope: InScope {i_a4TMf} > Type env: [] > Co env: []] > u_tys > tclvl 2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > arising from a type equality Vocab > i_a4TMf[sk:1] (Present * * > i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] > i_a4TNv[tau:2]) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.1 for x86_64-unknown-linux): > piResultTys1 > * > [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Repro (requires Nix & some download time, provides hard repro guarantees > in return): > > {{{ > $ git clone https://github.com/deepfire/holotype > $ cd holotype > $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a > $ nix-shell > [nix-shell:~/holotype]$ make > }}} New description: I apologize in advance for a non-minimised repro. The panic (with a small `-ddump-tc-trace` excerpt, but full log also attached): {{{ tcPolyExprNC Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcSkolemise tcInferId voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) tcCheckId voc_a4TB2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcWrapResult Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Expected: Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tc_sub_type_ds ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ty_expected = Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) deeply_instantiate final subst origin: arising from a use of ‘voc_a4TB2’ type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) subst: [TCvSubst In scope: InScope {i_a4TMf} Type env: [] Co env: []] u_tys tclvl 2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) arising from a type equality Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): piResultTys1 * [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro (requires Nix & some download time, provides hard repro guarantees in return): {{{ $ git clone https://github.com/deepfire/holotype $ cd holotype $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a $ nix-shell [nix-shell:~/holotype]$ cabal build lib:holotype }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 21:11:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 21:11:30 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.78f10adcb13effd2e6babad9193b595b@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): ..and the following is what hints at the cause (kind polymoprhism mismatch between `.hs` and `.hs-boot`): {{{ $ git diff HEAD~1.. diff --git a/src/Holo/Widget2.hs-boot b/src/Holo/Widget2.hs-boot index d63c757..13ed889 100644 --- a/src/Holo/Widget2.hs-boot +++ b/src/Holo/Widget2.hs-boot @@ -3,6 +3,7 @@ where import Data.Kind (Type) import qualified Data.TypeMap.Dynamic as TM +import GHC.Types (Constraint) import Generics.SOP (Top) import Generics.SOP.Monadic (Result) import Reflex (Dynamic) @@ -15,7 +16,7 @@ import {-# SOURCE #-} data Definition i a -newtype Vocab i c = Vocab (TM.TypeMap (HoloTag i)) +newtype Vocab (i ∷ Type) (c ∷ Type → Constraint) = Vocab (TM.TypeMap (HoloTag i)) data HoloTag i type Blank i = Item Top PBlank }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 21:30:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 21:30:53 -0000 Subject: [GHC] #14797: High-residency modules during GHC build In-Reply-To: <047.916b3a5a2bf47612a2c2ec6726c0a648@haskell.org> References: <047.916b3a5a2bf47612a2c2ec6726c0a648@haskell.org> Message-ID: <062.adda127a463a2de679833d3e0b224225@haskell.org> #14797: High-residency modules during GHC build -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It is indeed on our roadmap but don't let this stop you from pitching in. I agree that it would be nice to have more structured statistics. `-ddump- timings` is a good start but I do regret the choice of ad-hoc output. I think it would make a lot of sense to have this produce, for instance, some sort of simple JSON document which could be easily and reliably slurped into another language for analysis. While this is technically possible now I think I've implemented around three different fragile parsers. The same applies to `+RTS -t` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 21:33:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 21:33:20 -0000 Subject: [GHC] #13630: ByteString pinned memory can be leaky In-Reply-To: <042.fff951e1f463505474531ee41ed62718@haskell.org> References: <042.fff951e1f463505474531ee41ed62718@haskell.org> Message-ID: <057.8ef87a8f621afe398bf5e369a0384e26@haskell.org> #13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 21:57:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 21:57:08 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.721bf65233e1176651591ca5c5d46983@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): > > When you say "incorrect behaviour" do you meant that we get a seg-fault? Or just that we enter a closure that could be properly tagged? I mean the latter. Compiling the following code {{{#!hs module T15155 (a, B(..), b) where newtype A = A Int newtype B = B A {-# NOINLINE a #-} a = A 42 b = B a }}} to STG, I see: {{{#!hs T15155.a1 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=m, Unf=OtherCon []] = CCS_DONT_CARE GHC.Types.I#! [42#]; T15155.a [InlPrag=NOINLINE] :: T15155.A [GblId, Str=m, Unf=OtherCon []] = [] \u [] T15155.a1; T15155.b :: T15155.B [GblId, Str=m, Unf=OtherCon []] = [] \u [] T15155.a; }}} `a` and `b` look reasonably similar from their structure. The CMM picture is quite different: {{{ [section ""data" . T15155.a1_closure" { T15155.a1_closure: const GHC.Types.I#_con_info; const 42; }] [section ""data" . T15155.a_closure" { T15155.a_closure: const stg_IND_STATIC_info; const T15155.a1_closure+1; const 0; const 0; }] [section ""data" . T15155.b_closure" { T15155.b_closure: const stg_IND_STATIC_info; const T15155.a_closure; const 0; const 0; }] }}} There is no tag on the indirectee of `T15155.b_closure`, even if they possess equivalent unfoldings. Of course there is some obscure rule somewhere that strips the tag, so that no crash happens. For me "correct" would mean that `T15155.a_closure+1` is allowed and a being the consequence of {{{ T15155.a [InlPrag=NOINLINE] :: T15155.A [GblId, Str=m, >>>>Unf=OtherCon []<<<<] = [] \u [] T15155.a1; }}}. OTOH "not crashing" is merely law-abiding in my eyes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 22:23:16 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 22:23:16 -0000 Subject: [GHC] #16128: Pattern match checker should shortcut on simple cases Message-ID: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> #16128: Pattern match checker should shortcut on simple cases -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm autogenerating with TH some code that does a giant string pattern match on up to 60 cases. This match clause includes a default case, but nonetheless I get a warning: Pattern match checker exceeded (2000000) iterations in a case alternative. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) Note that in my case all the strings share a great deal in their common prefixes, which probably doesn't help matters. It seems to me that in a case like this, GHC should be able to just check that there are no duplicate strings (i.e. no overlaps) and that there is a default case (i.e. no incompleteness) rather than running the full checker algo. I'm not quite sure if there's a good way to generalize such a proposed shortcut so it is not too much of a special case, but likely something could be done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 22:34:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 22:34:47 -0000 Subject: [GHC] #16128: Pattern match checker should shortcut on simple cases In-Reply-To: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> References: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> Message-ID: <058.56eed5cc001ae42cc534eee0dc211f81@haskell.org> #16128: Pattern match checker should shortcut on simple cases -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 4 23:23:22 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Jan 2019 23:23:22 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.19401b704b8227033eccc870f0e9a10b@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): Commit `b87f5bf56e75042e4a55b5b806f6ff24021ea040` on the `ghc-16127-repros` branch of the `holotype` repository partially minimises the involved modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 01:48:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 01:48:46 -0000 Subject: [GHC] #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms, ViewPatterns and TypeFamilies Message-ID: <046.ac461540f23ca985d1ec6b615fb1659a@haskell.org> #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms, ViewPatterns and TypeFamilies -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language PatternSynonyms #-} {-# language ViewPatterns #-} {-# language TypeFamilies #-} module Bug where newtype GenLocated e = L e newtype WithSourceText a = WithSourceText a type StringLiteral = WithSourceText String {-# COMPLETE StringLiteral #-} pattern StringLiteral sl_s = WithSourceText sl_s type family SrcSpanLess a class HasSrcSpan a where decomposeSrcSpan :: a -> GenLocated (SrcSpanLess a) type instance SrcSpanLess (GenLocated e) = e instance HasSrcSpan (GenLocated a) where decomposeSrcSpan = id bug :: GenLocated StringLiteral -> String bug (decomposeSrcSpan->L (StringLiteral s)) = s workaround :: GenLocated StringLiteral -> String workaround (decomposeSrcSpan->L sl) = s where StringLiteral s = sl }}} {{{ $ ghci -Wincomplete-patterns Bug.hs GHCi, version 8.7.20190103: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/simon/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:27:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘bug’: Patterns not matched: _ | 27 | bug (decomposeSrcSpan->L (StringLiteral s)) = s | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ok, one module loaded. }}} I've been able to reproduce the issue with all versions of GHC >= 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 01:57:47 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 01:57:47 -0000 Subject: [GHC] #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms (was: Incorrect non-exhaustive pattern warning with PatternSynonyms, ViewPatterns and TypeFamilies) In-Reply-To: <046.ac461540f23ca985d1ec6b615fb1659a@haskell.org> References: <046.ac461540f23ca985d1ec6b615fb1659a@haskell.org> Message-ID: <061.f08f972d9248849eca51dcba57e44bb9@haskell.org> #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15753 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: PatternMatchWarnings => PatternMatchWarnings, PatternSynonyms * related: => #15753 Comment: Here is a simpler version without `ViewPatterns` or `TypeFamilies` (they aren't essential to triggering this bug): {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Bug where import Data.Functor.Identity pattern Id :: a -> Identity a pattern Id x = Identity x bug, workaround1, workaround2 :: Identity a -> a bug ia | Id a <- ia = a workaround1 ia | let ia' = ia , Identity a <- ia' = a workaround2 ia = a where Id a = ia }}} While this doesn't appear to be exactly the same bug as #15753, they feel related somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 01:58:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 01:58:39 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.ad96c0f16d3fa067b188284cce9bb66a@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15884, #16129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #15884 => #15884, #16129 Comment: #16129 is possibly related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 02:28:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 02:28:02 -0000 Subject: [GHC] #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms In-Reply-To: <046.ac461540f23ca985d1ec6b615fb1659a@haskell.org> References: <046.ac461540f23ca985d1ec6b615fb1659a@haskell.org> Message-ID: <061.024a8ec7e9a51a8cf652f962f5325dca@haskell.org> #16129: Incorrect non-exhaustive pattern warning with PatternSynonyms -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: | PatternMatchWarnings, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15753 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Urk, please ignore what I wrote in comment:1. I forgot to add a `COMPLETE` pragma on `Id`, and that makes the whole example invalid. Here is my second attempt at a minimal example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug where import Data.Functor.Identity {-# COMPLETE Id #-} pattern Id :: a -> Identity a pattern Id x = Identity x class Hm a where hm :: a -> a instance Hm (Identity a) where hm = id bug, workaround1, workaround2 :: Identity a -> a bug ia | Id a <- hm ia = a workaround1 ia | let ia' = hm ia , Identity a <- ia' = a workaround2 ia = a where Id a = hm ia }}} This time, I'm convinced that this is a duplicate of #15753, as this has the distinctive function-application-in-pattern-guard look that #15753 has. Closing as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 02:36:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 02:36:38 -0000 Subject: [GHC] #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc In-Reply-To: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> References: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> Message-ID: <056.b68dbab434e893a3f83aabcc56aa860b@haskell.org> #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc -------------------------------------+------------------------------------- Reporter: pl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: c++ | exceptions Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): [[https://mail.haskell.org/pipermail/ghc-devs/2019-January/016748.html|As explained on GHC-devs]] I ran into this in our `haskell-opencv` library. I can confirm that adding the following to the cabal file of my minimal isolated test-case fixes the problem: {{{ if os(darwin) ld-options: -Wl,-keep_dwarf_unwind }}} Shouldn't GHC pass these options by default when linking on OS X? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 02:37:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 02:37:00 -0000 Subject: [GHC] #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc In-Reply-To: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> References: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> Message-ID: <056.2fad422d28dae7907344390d81e42ffd@haskell.org> #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc -------------------------------------+------------------------------------- Reporter: pl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: c++ | exceptions Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 02:47:07 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 02:47:07 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.2e9315d2ff169510910377d18dc4843d@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15884, #16129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:6 RyanGlScott]: Not sure if this is a useful reduction: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Bug where {-# COMPLETE Id #-} pattern Id :: () -> () pattern Id a = a bug :: () -> () bug ia | Id a <- id ia = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 03:08:30 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 03:08:30 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.54749f582da87c39406579deae423357@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Alas, I can't follow the directions to reproduce this, as it fails quite early for me: {{{ $ nix-shell unpacking 'https://github.com/NixOS/nixpkgs/archive/cd68a8c7cc602e75a4abbadc94663347a73ae24e.tar.gz'... error: undefined variable 'stdenv' at /home/rgscott/Documents/Hacking/Haskell/holotype/manual- overrides.nix:24:15 (use '--show-trace' to show detailed location information) }}} If you could produce a reproducible example without the steep requirement to install Nix or `reflex`, that would be greatly helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 03:21:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 03:21:21 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" Message-ID: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ----------------------------------------+--------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When building the latest `opencv-extra` library on OS X I'm getting a GHC panic. To reproduce git clone https://github.com/LumiGuide/haskell-opencv, make sure Nix is installed and execute: {{{ > nix-build -A haskellPackages.opencv-extra ... [11 of 11] Compiling OpenCV.Extra ( src/OpenCV/Extra.hs, dist/build/OpenCV/Extra.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l" CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get }}} The library builds successfully on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 04:53:12 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 04:53:12 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.16bce097c1b7b5f36c95b4156f3479a2@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I apologize in advance for a non-minimised repro. > > The panic (with a small `-ddump-tc-trace` excerpt, but full log also > attached): > > {{{ > tcPolyExprNC > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcSkolemise > tcInferId > voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > tcCheckId > voc_a4TB2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tcWrapResult > Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > Expected: Check{Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} > tc_sub_type_ds > ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ty_expected = Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > deeply_instantiate final subst > origin: arising from a use of ‘voc_a4TB2’ > type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > subst: [TCvSubst > In scope: InScope {i_a4TMf} > Type env: [] > Co env: []] > u_tys > tclvl 2 > Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) > arising from a type equality Vocab > i_a4TMf[sk:1] (Present * * > i_a4TMf[sk:1]) > ~ > Vocab > * > (k_a4TNy[tau:2] -> Constraint) > i_a4TNv[tau:2] > (Present * k_a4TNy[tau:2] > i_a4TNv[tau:2]) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.1 for x86_64-unknown-linux): > piResultTys1 > * > [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Repro (requires Nix & some download time, provides hard repro guarantees > in return): > > {{{ > $ git clone https://github.com/deepfire/holotype > $ cd holotype > $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a > $ nix-shell > [nix-shell:~/holotype]$ cabal build lib:holotype > }}} New description: I apologize in advance for a non-minimised repro. The panic (with a small `-ddump-tc-trace` excerpt, but full log also attached): {{{ tcPolyExprNC Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcSkolemise tcInferId voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) tcCheckId voc_a4TB2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcWrapResult Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Expected: Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tc_sub_type_ds ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ty_expected = Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) deeply_instantiate final subst origin: arising from a use of ‘voc_a4TB2’ type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) subst: [TCvSubst In scope: InScope {i_a4TMf} Type env: [] Co env: []] u_tys tclvl 2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) arising from a type equality Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): piResultTys1 * [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro (requires Nix & some download time, provides hard repro guarantees in return): {{{ $ git clone https://github.com/deepfire/holotype $ cd holotype $ git reset --hard 5c80e9239a3c18d67106920db8f832abc7bd9a93 $ nix-shell [nix-shell:~/holotype]$ cabal build lib:holotype }}} -- Comment (by _deepfire): Ryan, I apologize for the repro fiasco -- I've reproduced your problem in a different environment and fixed it in commit `5c80e9239a3c18d67106920db8f832abc7bd9a93`. . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 05:08:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 05:08:22 -0000 Subject: [GHC] #16131: -ddump-cmm doesn't work when compiling cmm files Message-ID: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> #16131: -ddump-cmm doesn't work when compiling cmm files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to see Cmm generated for `StgMiscClosures.cmm` so I tried adding `-ddump-cmm` to the command the build system runs to build it, which doesn't work: {{{ $ "inplace/bin/ghc-stage1" -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o -fforce-recomp -ddump-cmm }}} Why do I need cmm dumps of cmm files? - When building Cmm even the parser does code generation, so the Cmm after parsing is quite different than the input and contains useful information. - I want all macros to be expanded, running CPP manually is painful. - I currently can't see output of Cmm optimisations when building Cmm files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 05:42:13 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 05:42:13 -0000 Subject: [GHC] #16131: -ddump-cmm doesn't work when compiling cmm files In-Reply-To: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> References: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> Message-ID: <058.e8e5fa6eff77fa95494956a106e14792@haskell.org> #16131: -ddump-cmm doesn't work when compiling cmm files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/76 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 06:23:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 06:23:03 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.bbe61c3a3fea17d1ccdaeb76d763693b@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15884, #16129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Another (tiny) reduction: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Bug where {-# COMPLETE Id #-} pattern Id :: () pattern Id = () bug :: () bug | Id <- id () = () }}} {{{ Bug.hs:9:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘bug’: Guards do not cover entire pattern space | 9 | bug | Id <- id () = () | ^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 09:01:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 09:01:39 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.99215dfb7e16de06f87ee1a27485746b@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ----------------------------------------+--------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by trommler): I have put up a branch on GHC's Gitlab as [[https://gitlab.haskell.org/ghc/ghc/tree/wip/T15916|wip/T15916]]. Note, this branch only works on powerpc64 with a workaround for #15411. I had some trouble with my FreeBSD 11 locale setup and could not run the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 10:57:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 10:57:18 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.3269d2c354ff1c5c1d6dad5226620d06@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ----------------------------------------+--------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by pkubaj): I don't see a patch for #15411. Could you upload it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 11:10:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 11:10:19 -0000 Subject: [GHC] #16132: ./validate --slow: "dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory)" Message-ID: <046.8af5b3629a54e29f18d6737a808edde1@haskell.org> #16132: ./validate --slow: "dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory)" --------------------------------------+--------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- I had checked out D5067 at https://phabricator.haskell.org/D5067?id=19263 with {{{ arc patch D5067 }}} Then I ran {{{ env THREADS=9 ./validate }}} and got a few test failures. When I then ran {{{ env THREADS=9 ./validate --slow }}} I got the following error: {{{ /usr/bin/install -c -m 755 -d "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts" for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.7.20190105.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug- ghc8.7.20190105.so rts/dist/build/libHSrts_thr-ghc8.7.20190105.so rts/dist/build/libHSrts_thr_debug-ghc8.7.20190105.so rts/dist/build /libHSrts_l-ghc8.7.20190105.so rts/dist/build/libHSrts_thr_l- ghc8.7.20190105.so rts/dist/build/libHSrts_thr_debug_p.a rts/dist/build/libHSrts_debug_p.a rts/dist/build/libffi.so.7.1.0 rts/dist/build/libffi.so.7 rts/dist/build/libffi.so rts/dist/build/libCffi.a rts/dist/build/libCffi_p.a rts/dist/build/libCffi_l.a rts/dist/build/libCffi_debug.a rts/dist/build/libCffi_thr.a rts/dist/build/libCffi_thr_debug.a rts/dist/build/libCffi_thr_l.a rts/dist/build/libCffi_thr_p.a rts/dist/build/libCffi_thr_debug_p.a rts/dist/build/libCffi_debug_p.a; do case $i in *.a) /usr/bin/install -c -m 644 $i "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts"; true "/home/simon/src/ghc-validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/home/simon/src/ghc-validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts" ; strip "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts";; *) /usr/bin/install -c -m 644 $i "/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105/rts"; esac; done "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/home/simon/src/ghc- validate/bindisttest/install dir' '/home/simon/src/ghc- validate/bindisttest/install dir/lib/ghc-8.7.20190105' '/home/simon/src /ghc-validate/bindisttest/install dir/share/doc/ghc-8.7.20190105/html/libraries' 'v p dyn' Installing library in /home/simon/src/ghc-validate/bindisttest/install dir/lib/ghc-8.7.20190105/ghc-prim-0.5.3 dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory) ghc.mk:986: recipe for target 'install_packages' failed make[3]: *** [install_packages] Error 1 Makefile:51: recipe for target 'install' failed make[2]: *** [install] Error 2 bindisttest/ghc.mk:21: recipe for target 'test_bindist' failed make[1]: *** [test_bindist] Error 2 Makefile:123: recipe for target 'test_bindist' failed make: *** [test_bindist] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 11:26:08 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 11:26:08 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.f12ee3b9b44339d13a3fee258dc22740@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15916 Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * Attachment "Disable-unboxed-arrays.patch" added. Workaround so we can build GHC on PowerPC 64-bit big-endian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 11:29:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 11:29:32 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.c5edb3dcb2818c588147e8393f48ac2d@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ----------------------------------------+--------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by trommler): Replying to [comment:8 pkubaj]: > I don't see a patch for #15411. Could you upload it? I attached the patch, which I prepared for openSUSE, to #15411. Here is a direct link: https://ghc.haskell.org/trac/ghc/attachment/ticket/15411 /Disable-unboxed-arrays.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 12:04:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 12:04:55 -0000 Subject: [GHC] #16132: ./validate --slow: "dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory)" In-Reply-To: <046.8af5b3629a54e29f18d6737a808edde1@haskell.org> References: <046.8af5b3629a54e29f18d6737a808edde1@haskell.org> Message-ID: <061.740e59887077b26980b310377bcc749a@haskell.org> #16132: ./validate --slow: "dist-install/build/HSghc-prim-0.5.3.o: copyFile: does not exist (No such file or directory)" -------------------------------+-------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by sjakobi): Strange. Even when I `git clean -xfd` before slow-validating, I still see the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:20:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:20:19 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.922ba8fe7e3d0bc2fb96237b1f069766@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This can be minimized down to the following four modules: {{{#!hs -- A.hs module A (Vocab(..)) where import Data.Kind import {-# SOURCE #-} B data T i = MkT i thisPanics :: x thisPanics = method (MkT 'a') }}} {{{#!hs -- A.hs-boot {-# LANGUAGE PolyKinds #-} module A where data T i }}} {{{#!hs -- B.hs module B where import A class C i where method :: T i -> x }}} {{{#!hs -- B.hs-boot module B where import {-# SOURCE #-} A class C i where method :: T i -> x }}} ----- {{{ $ /opt/ghc/8.6.3/bin/ghc A.hs [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B[boot] ( B.hs-boot, B.o-boot ) [3 of 4] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): piResultTys1 * [i_aYf[tau:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:43:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:43:15 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.ffed342a00504d7a77fe71b2b88248a3@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12045TH{1,2}, | typecheck/should_compile/T12045a, | typecheck/should_fail/T12045{b,c}, | parser/should_fail/T12045d, | parser/should_compile/T12045e Blocked By: | Blocking: 14579 Related Tickets: #15782 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T12045TH{1,2}, typecheck/should_compile/T12045a, typecheck/should_fail/T12045{b,c}, parser/should_fail/T12045d, parser/should_compile/T12045e * resolution: => fixed * milestone: => 8.8.1 Comment: Merged in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:50:36 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:50:36 -0000 Subject: [GHC] #14366: Type family equation refuses to unify wildcard type patterns In-Reply-To: <050.99fc7b3497a7cbec29b57a49c9d2896b@haskell.org> References: <050.99fc7b3497a7cbec29b57a49c9d2896b@haskell.org> Message-ID: <065.278fe9b40802b94baea3209b35990ce7@haskell.org> #14366: Type family equation refuses to unify wildcard type patterns -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T14366 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_compile/T14366 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:51:43 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:51:43 -0000 Subject: [GHC] #15362: Template Haskell ignores bad type family definitions In-Reply-To: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> References: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> Message-ID: <062.d8ee73eb928337d1006bd1ec295feb48@haskell.org> #15362: Template Haskell ignores bad type family definitions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15362 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => th/T15362 * differential: => Phab:D5229 * resolution: => fixed * milestone: 8.10.1 => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:54:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:54:23 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.c8fa2889539b6c7829cb66e76bac75b2@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{b}, | typecheck/should_fail/T15592a Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: polykinds/T15592, T15592b => polykinds/T15592{b}, typecheck/should_fail/T15592a * differential: => Phab:D5229 Comment: A test case for comment:2 was added in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:55:36 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:55:36 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.2bdd9e48a91da65b935ce4ad410f55fb@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: #12045 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T15788 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_compile/T15788 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:56:43 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:56:43 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.24569cb8cb6eb7e713cde3e51661421f@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T15793 Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T15793 * status: new => closed * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 15:58:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 15:58:16 -0000 Subject: [GHC] #15797: GHC panic using visible kind application In-Reply-To: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> References: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> Message-ID: <066.40783582f30b65a193b86e4d49849db0@haskell.org> #15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T15797 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 16:01:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 16:01:19 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.f0b50b4086aac4a55d2699ca746aab53@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15799 Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T15799 * differential: => Phab:D5229 Comment: A test case for this was added in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} But it's unclear to me if this issue is actually fixed, based on the discussion in comment:3 and comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 16:02:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 16:02:38 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.f9ae6c2687174dcbf63ff551c90bdfc9@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15801 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T15801 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: The test case (alluded to in comment:2) was added in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 16:03:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 16:03:52 -0000 Subject: [GHC] #15807: GHC panic with visible kind applications In-Reply-To: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> References: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> Message-ID: <066.106382a415aa7ce3ff99a5a63c9bb6ca@haskell.org> #15807: GHC panic with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15807 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T15807 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 16:05:07 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 16:05:07 -0000 Subject: [GHC] #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message In-Reply-To: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> References: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> Message-ID: <066.6452645c9e6a40462a2b15d89722814a@haskell.org> #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15816 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T15816 * differential: => Phab:D5229 * resolution: => fixed * milestone: => 8.8.1 Comment: This was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 16:18:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 16:18:23 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.0b1f0faba01066613f2019212a09f517@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, Wiki Page: | Phab:D5229 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: deriving/should_compile/T14579 => deriving/should_compile/T14579{a} * differential: Phab:D4264 => Phab:D4264, Phab:D5229 Comment: A test case was added in [https://gitlab.haskell.org/ghc/ghc/commit/17bd163566153babbf51adaff8397f948ae363ca 17bd163566153babbf51adaff8397f948ae363ca]: {{{ Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} To ensure that the code in comment:12 actually typechecks. However, the task of making `GeneralizedNewtypeDeriving` actually generate this code remains to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 17:36:56 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 17:36:56 -0000 Subject: [GHC] #16133: TH can sneak in TypeApplications without enabling the extension Message-ID: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> #16133: TH can sneak in TypeApplications without enabling the extension -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug1 where import Language.Haskell.TH $([d| f :: Int f = $(varE 'id `appTypeE` conT ''Int `appE` litE (integerL 42)) |]) }}} But it shouldn't: this splices in code that uses `TypeApplications`, but the language extension isn't enabled! What's worse, this is inconsistent with visible kind applications, since the following code //is// rejected: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug2 where import Data.Kind import Language.Haskell.TH hiding (Type) data P (a :: k) = MkP $([d| type P' = $(conT ''P `appKindT` conT ''Type) |]) }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug2.hs [1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o ) Bug2.hs:10:3: error: Illegal visible kind application ‘Type’ Perhaps you intended to use TypeApplications | 10 | $([d| type P' = $(conT ''P `appKindT` conT ''Type) |]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Let's bring the two into harmony. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 17:46:27 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 17:46:27 -0000 Subject: [GHC] #16133: TH can sneak in TypeApplications without enabling the extension In-Reply-To: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> References: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> Message-ID: <065.8d82369adf73ebb8e55073403248a07e@haskell.org> #16133: TH can sneak in TypeApplications without enabling the extension -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/77 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/77 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 18:29:06 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 18:29:06 -0000 Subject: [GHC] #16134: Continuous integration on FreeBSD Message-ID: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> #16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Arrowd has been looking at introducing CI for FreeBSD/amd64. He has a build script using poudriere [[http://arrowd.name/ghc-ci|here]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 18:39:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 18:39:22 -0000 Subject: [GHC] #16134: Continuous integration on FreeBSD In-Reply-To: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> References: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> Message-ID: <061.cdb6f71969edea79246021e61f75cce0@haskell.org> #16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * component: Compiler => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 21:27:54 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 21:27:54 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.c7a52c2e59c49dc6e8cc1b07a9a72fdb@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, Wiki Page: | Phab:D5229 -------------------------------------+------------------------------------- Comment (by RyanGlScott): When writing comment:12, I was originally hopeful that we could scrap all of commit 649e777211fe08432900093002547d7358f92d82—that is, that we could avoid generating any explicit kind signatures and exclusively use visible kind application. Alas, this is not the case. Consider this tortuous example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Kind import Data.Proxy -- type P :: forall {k} {t :: k}. Proxy t type P = 'Proxy -- type Wat :: forall a. Proxy a -> * newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) deriving Eq -- type Wat2 :: forall {a}. Proxy a -> * type Wat2 = Wat -- type Glurp :: * -> * newtype Glurp a = MkGlurp (Wat2 (P :: Proxy a)) deriving Eq }}} This compiles with GHC 8.6.3. However, if I try to switch `GeneralizedNewtypeDeriving` over to using exclusively visible kind applications, then the code that it generates no longer compiles: {{{ $ ghc/inplace/bin/ghc-stage2 Bug.hs -ddump-deriv [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Derived instances ==================== Derived class instances: instance forall a (x :: Data.Proxy.Proxy a). GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Wat x) where (GHC.Classes.==) = GHC.Prim.coerce @(GHC.Maybe.Maybe a_a1wk -> GHC.Maybe.Maybe a_a1wk -> GHC.Types.Bool) @(Bug.Wat @a_a1wk x_a210 -> Bug.Wat @a_a1wk x_a210 -> GHC.Types.Bool) ((GHC.Classes.==) @(GHC.Maybe.Maybe a_a1wk)) :: Bug.Wat @a_a1wk x_a210 -> Bug.Wat @a_a1wk x_a210 -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @(GHC.Maybe.Maybe a_a1wk -> GHC.Maybe.Maybe a_a1wk -> GHC.Types.Bool) @(Bug.Wat @a_a1wk x_a210 -> Bug.Wat @a_a1wk x_a210 -> GHC.Types.Bool) ((GHC.Classes./=) @(GHC.Maybe.Maybe a_a1wk)) :: Bug.Wat @a_a1wk x_a210 -> Bug.Wat @a_a1wk x_a210 -> GHC.Types.Bool instance GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Glurp a) where (GHC.Classes.==) = GHC.Prim.coerce @(Bug.Wat2 Bug.P -> Bug.Wat2 Bug.P -> GHC.Types.Bool) @(Bug.Glurp a_avE -> Bug.Glurp a_avE -> GHC.Types.Bool) ((GHC.Classes.==) @(Bug.Wat2 Bug.P)) :: Bug.Glurp a_avE -> Bug.Glurp a_avE -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @(Bug.Wat2 Bug.P -> Bug.Wat2 Bug.P -> GHC.Types.Bool) @(Bug.Glurp a_avE -> Bug.Glurp a_avE -> GHC.Types.Bool) ((GHC.Classes./=) @(Bug.Wat2 Bug.P)) :: Bug.Glurp a_avE -> Bug.Glurp a_avE -> GHC.Types.Bool Derived type family instances: Bug.hs:21:12: error: • Couldn't match representation of type ‘a0’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:21:12-13 • In the expression: GHC.Prim.coerce @(Wat2 P -> Wat2 P -> Bool) @(Glurp a -> Glurp a -> Bool) ((==) @(Wat2 P)) :: Glurp a -> Glurp a -> Bool In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat2 P -> Wat2 P -> Bool) @(Glurp a -> Glurp a -> Bool) ((==) @(Wat2 P)) :: Glurp a -> Glurp a -> Bool When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (==) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:21:12) | 21 | deriving Eq | ^^ Bug.hs:21:12: error: • Couldn't match representation of type ‘a1’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:21:12-13 • In the expression: GHC.Prim.coerce @(Wat2 P -> Wat2 P -> Bool) @(Glurp a -> Glurp a -> Bool) ((/=) @(Wat2 P)) :: Glurp a -> Glurp a -> Bool In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat2 P -> Wat2 P -> Bool) @(Glurp a -> Glurp a -> Bool) ((/=) @(Wat2 P)) :: Glurp a -> Glurp a -> Bool When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (/=) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:21:12) | 21 | deriving Eq | ^^ }}} Ambiguity once again rears its ugly head. You might be tempted to think that we could sprinkle `@a` somewhere in `Wat2 P` to resolve the ambiguity, but this is impossible, as all of the type variable binders in `Wat2` and `P` are inferred, making them unavailable for visible kind application. The only way out of this mess is to surround `P` with an explicit kind signature (i.e., `(P :: Proxy a)`). That being said, visible kind application will help us quite a bit, as we can avoid generating explicit kind signatures whenever a tycon only has specified or required type variable binders in its kind. But we'll still need to keep around the hack in commit 649e777211fe08432900093002547d7358f92d82 in the event that there are any inferred type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 22:18:04 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 22:18:04 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.6681c80c32cfe18b3e9cf3eb84efceb5@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, Wiki Page: | Phab:D5229 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Cruelly enough, comment:20 means the the original program in this ticket must have an explicit kind signature anyway, since in the kind of `'Proxy`: {{{#!hs 'Proxy :: forall {k} (a :: k). Proxy a }}} We have an inferred type variable binder! Argh. I wonder if we can be a bit smarter about where we put explicit kind signatures? This is the code that GHC 8.6.3 currently generates for the original program's `Eq (Glurp a)` instance: {{{ instance GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Glurp a) where (GHC.Classes.==) = GHC.Prim.coerce @((Bug.Wat (Data.Proxy.Proxy :: (Data.Proxy.Proxy a_a1Dx :: TYPE GHC.Types.LiftedRep)) :: TYPE GHC.Types.LiftedRep) -> (Bug.Wat (Data.Proxy.Proxy :: (Data.Proxy.Proxy a_a1Dx :: TYPE GHC.Types.LiftedRep)) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Glurp a_a1Dx -> Bug.Glurp a_a1Dx -> GHC.Types.Bool) (GHC.Classes.==) :: Bug.Glurp a_a1Dx -> Bug.Glurp a_a1Dx -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @((Bug.Wat (Data.Proxy.Proxy :: (Data.Proxy.Proxy a_a1Dx :: TYPE GHC.Types.LiftedRep)) :: TYPE GHC.Types.LiftedRep) -> (Bug.Wat (Data.Proxy.Proxy :: (Data.Proxy.Proxy a_a1Dx :: TYPE GHC.Types.LiftedRep)) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Glurp a_a1Dx -> Bug.Glurp a_a1Dx -> GHC.Types.Bool) (GHC.Classes./=) :: Bug.Glurp a_a1Dx -> Bug.Glurp a_a1Dx -> GHC.Types.Bool }}} There are many explicit kind signatures here that are completely redundant—for instance, each `(_ :: TYPE GHC.Types.LiftedRep)` signature is redundant, since they're not needed to fix any type variables. The only signature that's strictly necessary is the `(Data.Proxy.Proxy :: (Data.Proxy.Proxy a_a1Dx :: ...))` one, since that fixes `a_a1Dx`. Perhaps we should adopt a more fine-grained heuristic (besides the mere presence of inferred type variable binders) to determine when to insert explicit kind signatures? For instance, the `reify_tc_app` function in `TcSplice` (which reifies applications of tycons) uses a more complicated heuristic: if the free variables of the tycon's kind are not a subset of the free variables of the arguments in injective positions, then it needs an explicit signature. (This is explained in [https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1824-1917 this Note]). This heuristic could work well in this situation as well. We'd need to modify the definition of "injective positions" to include specified arguments (currently it only includes required ones), but if we did, then I believe we could drop all of the explicit signatures in the original program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 5 22:34:27 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Jan 2019 22:34:27 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.fbd201e4faea394a05d3350fbbf566f5@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have started looking into fixing this on top of GitLab CI (https://gitlab.haskell.org/ghc/ghc/merge_requests/79). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 03:33:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 03:33:19 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.623941a1112c10000f2423cfa298007a@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: | JulianLeviston Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * owner: (none) => JulianLeviston Comment: Even though I haven't finished my first two training wheels tickets, this is the one I really want to fix, so I'm going to at least start on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 04:37:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 04:37:23 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.3ba001eb24e97aba8e9eab9b4b92f709@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: | JulianLeviston Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Great! Do ping if you get stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 05:56:58 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 05:56:58 -0000 Subject: [GHC] #16131: -ddump-cmm doesn't work when compiling cmm files In-Reply-To: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> References: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> Message-ID: <058.e10a71322d8ceaf79937ca71ad66ed0a@haskell.org> #16131: -ddump-cmm doesn't work when compiling cmm files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 09:06:08 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 09:06:08 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.18bea4a219eaa0a4497d94e270e1ba73@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonmar (added) Comment: I came across something interesting. While digging deeper I found that this is where we assign a location of heap (instead of location of the arena where we allocate cost centre stacks) to a closure's CCS field: {{{ #0 0x0000000000a15794 in raiseAsync (cap=0xd35700 , tso=0x420320f000, exception=0xb570c0, stop_at_atomically=false, stop_here=0x0) at rts/RaiseAsync.c:873 #1 0x0000000000a14aa6 in throwToMsg (cap=0xd35700 , msg=0x42000be730) at rts/RaiseAsync.c:275 #2 0x0000000000a148f0 in throwTo (cap=0xd35700 , source=0x4205b6f728, target=0x420320f000, exception=0xb570c0) at rts/RaiseAsync.c:213 #3 0x0000000000a3c323 in stg_killThreadzh () #4 0x0000000000000000 in ?? () }}} The closure (an `AP_STACK`) previously has this cost centre stack: {{{ >>> print ((StgClosure *) 0x4200345e70)->header.prof.ccs $30 = (CostCentreStack *) 0xb44390 >>> print *((StgClosure *) 0x4200345e70)->header.prof.ccs $31 = { ccsID = 241, cc = 0xb44350, prevStack = 0xd2df00 , indexTable = 0x0, root = 0xb44390, depth = 1, scc_count = 0, selected = 1, time_ticks = 0, mem_alloc = 59522362, inherited_alloc = 0, inherited_ticks = 0 } }}} The new value is `0x4207528000`, a location in the heap. The new location is coming from another closure so I should debug more and see how the value ended up in that closure, but I noticed a `TODO` comment around the code that makes this assignment: {{{ -- RaiseAsync.c:873 SET_HDR(ap,&stg_AP_STACK_info, ((StgClosure *)frame)->header.prof.ccs /* ToDo */); }}} I wonder if that `ToDo` has anything to do with this. @simonmar, any ideas? The commit that added that `ToDo`: b1953bbb1ed3cb16497e5447db7487f0c2d9e41a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 09:28:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 09:28:32 -0000 Subject: [GHC] #16135: Panic with ExistentialQuantification and ApplicativeDo Message-ID: <053.2647af571b23876e29228e6722df209d@haskell.org> #16135: Panic with ExistentialQuantification and ApplicativeDo -------------------------------------+------------------------------------- Reporter: Ashley | Owner: (none) Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE ExistentialQuantification, ApplicativeDo #-} module Bug where data T f = forall a. MkT (f a) runf :: forall f. Functor f => IO (T f) runf = do return () MkT fa <- runf return $ MkT fa }}} {{{ Bug.hs:11:18: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): No skolem info: [a_a1nb[ssk:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 09:39:56 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 09:39:56 -0000 Subject: [GHC] #16135: Panic with ExistentialQuantification and ApplicativeDo In-Reply-To: <053.2647af571b23876e29228e6722df209d@haskell.org> References: <053.2647af571b23876e29228e6722df209d@haskell.org> Message-ID: <068.442746ca516263d639251715f6d4f225@haskell.org> #16135: Panic with ExistentialQuantification and ApplicativeDo -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Ashley Yakeley: Old description: > {{{ > {-# LANGUAGE ExistentialQuantification, ApplicativeDo #-} > > module Bug where > > data T f = forall a. MkT (f a) > > runf :: forall f. Functor f => IO (T f) > runf = do > return () > MkT fa <- runf > return $ MkT fa > }}} > > {{{ > > Bug.hs:11:18: error:ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-unknown-linux): > No skolem info: > [a_a1nb[ssk:2]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in > ghc:TcErrors > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: {{{#!hs {-# LANGUAGE ExistentialQuantification, ApplicativeDo #-} module Bug where data T f = forall a. MkT (f a) runf :: forall f. Functor f => IO (T f) runf = do return () MkT fa <- runf return $ MkT fa }}} {{{ Bug.hs:11:18: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): No skolem info: [a_a1nb[ssk:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 10:33:30 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 10:33:30 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.04bcc37e841e4a372d1012b076143afb@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 11:34:54 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 11:34:54 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.e6cc7ecde749bff0e4290fea2486b553@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: unicode Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15525 | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by lelf): * keywords: => unicode -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 12:03:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 12:03:55 -0000 Subject: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64 In-Reply-To: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> References: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> Message-ID: <057.b28c676efcbb8e1e87dcb0fa115ac311@haskell.org> #4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 12:34:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 12:34:02 -0000 Subject: [GHC] #16136: Broken link to GHC-Prim.html#chr%23 Message-ID: <054.684ad8d9bc76b518dddfed5912a9ac95@haskell.org> #16136: Broken link to GHC-Prim.html#chr%23 -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When on page http://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.12.0.0 /GHC-Exts.html#v:chr-35- you click on Source of chr#, you get "404 Not Found" at this address http://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- prim-0.5.3/src/GHC-Prim.html#chr%23 It works fine for https://hackage.haskell.org/package/ghc- prim-0.5.3/docs/src/GHC.Prim.html#chr%23 so I think it's GHC's problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 16:49:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 16:49:01 -0000 Subject: [GHC] #16135: Panic with ExistentialQuantification and ApplicativeDo In-Reply-To: <053.2647af571b23876e29228e6722df209d@haskell.org> References: <053.2647af571b23876e29228e6722df209d@haskell.org> Message-ID: <068.30d6aa8a1a0bb01780317c4f258e0084@haskell.org> #16135: Panic with ExistentialQuantification and ApplicativeDo -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 17:08:57 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 17:08:57 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.a3f202257e53ef6e3ce39f5899cc9be0@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): @pkubaj, I also have the patches based on the 8.6.3 release in https://gitlab.haskell.org/trommler/ghc/commits/wip/T15916. They most likely also apply cleanly to other 8.6 releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 18:15:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 18:15:18 -0000 Subject: [GHC] #16137: unhelpful parse error message: Unexpected do block in function application Message-ID: <049.655fdb7342fd21147796be4f8ceb71cf@haskell.org> #16137: unhelpful parse error message: Unexpected do block in function application -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not a bug, as ghc correctly rejects an invalid program. But I have the impression that the error message is getting less precise (for reason and location) from 8.4 to 8.6: {{{ foo = do let x = case y of Nothing -> True bar }}} 8.6.3 says {{{ P.hs:1:7: error: Unexpected do block in function application: do let x = ... You could write it with parentheses Or perhaps you meant to enable BlockArguments? | 1 | foo = do | ^^... }}} I am not seeing what application ghc thinks of. 8.4.4 had the more useful {{{ P.hs:3:5: error: parse error on input ‘Nothing’ | 3 | Nothing -> True | ^^^^^^^ }}} More useful, since in the actual code, from which I distilled the above, there were a dozen lines between the locations that were reported by 8.6.3 and 8.4.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 19:53:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 19:53:15 -0000 Subject: [GHC] #16137: unhelpful parse error message: Unexpected do block in function application In-Reply-To: <049.655fdb7342fd21147796be4f8ceb71cf@haskell.org> References: <049.655fdb7342fd21147796be4f8ceb71cf@haskell.org> Message-ID: <064.d9bac993987aea08a591422cabceafca@haskell.org> #16137: unhelpful parse error message: Unexpected do block in function application -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16097 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #16097 Comment: Closing as a delicate of #16097. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 21:37:57 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 21:37:57 -0000 Subject: [GHC] #16097: Bad error message for a misaligned case block in a do-let expression In-Reply-To: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> References: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> Message-ID: <060.9b44942c3c898e47d6d0f961ce008d21@haskell.org> #16097: Bad error message for a misaligned case block in a do-let expression -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): The error message ("in function application") is wrong? The underlined part (the "do") is not an application. Agree with svenpanne. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 21:41:36 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 21:41:36 -0000 Subject: [GHC] #16138: Export GHC.TypeNats.natSing for TypeApplications Message-ID: <052.ad7dee7c1bf3c8a0b99156dd688d3484@haskell.org> #16138: Export GHC.TypeNats.natSing for TypeApplications -------------------------------------+------------------------------------- Reporter: HateUsernames | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Now that TypeApplications is available `natSing` can be exposed so that it can be directly used like `natSing @n`. This allows for Proxy not to be used. http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.TypeNats.html#KnownNat -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 22:48:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 22:48:22 -0000 Subject: [GHC] #16138: Export GHC.TypeNats.natSing for TypeApplications In-Reply-To: <052.ad7dee7c1bf3c8a0b99156dd688d3484@haskell.org> References: <052.ad7dee7c1bf3c8a0b99156dd688d3484@haskell.org> Message-ID: <067.409327dd39dfa9ce93232c5a9f086e67@haskell.org> #16138: Export GHC.TypeNats.natSing for TypeApplications -------------------------------------+------------------------------------- Reporter: HateUsernames | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15183 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15183 Comment: Closing as a duplicate of #15183. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 6 23:37:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Jan 2019 23:37:20 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.bb0318d01b11b1725c094b5b46f6f1d5@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): https://gitlab.haskell.org/ghc/ghc/commit/9ea8dcea3e5ba96808ef91028e0efde9d31f7272 is now merged. We will build p_o in hadrain as well, but this only happens when `dynamicGhcPrograms = return False`. This behavior is different from `make`. Given that libghci can be used by external interpreter, shall we still build it even when `dynamicGhcPrograms` is true? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 00:56:26 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 00:56:26 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints Message-ID: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley | Owner: (none) Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints #-} module Bug where import Data.Constraint type E (c :: * -> Constraint) = forall (a :: *). Eq a => c a }}} {{{ Bug.hs:5:58: error: • Expected a type, but ‘c a’ has kind ‘Constraint’ • In the type ‘forall (a :: *). Eq a => c a’ In the type declaration for ‘E’ | 5 | type E (c :: * -> Constraint) = forall (a :: *). Eq a => c a | ^^^ }}} Note that GHC accepts the program when the `Eq a` constraint is removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 00:58:37 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 00:58:37 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.40974a08356709864517fb76cc523259@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): Simpler program that is also incorrectly rejected: {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints #-} module Bug where import Data.Constraint type E = forall (a :: *). Eq a => Num a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 01:07:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 01:07:52 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.c33993e978bc5d1e1f54cdefc38dd0e6@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): You can work around this by annotating the result with a kind signature: {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints #-} module Bug where import Data.Kind type E = (forall (a :: *). Eq a => Num a :: Constraint) }}} (FWIW, I am also confused as to why GHC doesn't just accept your definition as-is.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 02:28:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 02:28:10 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes Message-ID: <053.4084568d524ce1292251a51835a53ec6@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley | Owner: (none) Yakeley | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints, FlexibleInstances, UndecidableInstances #-} module Bug where type F1 (f :: * -> *) = forall a. Eq (f a) class (Functor f, F1 f) => C f instance (Functor f, F1 f) => C f type F2 f = (Functor f, F1 f) }}} {{{ Bug.hs:7:1: error: • Illegal polymorphic type: F1 f GHC doesn't yet support impredicative polymorphism • In the type synonym declaration for ‘F2’ | 7 | type F2 f = (Functor f, F1 f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} (GHC accepts the program with ImpredicativeTypes.) `(Functor f, F1 f)` is allowed as a superclass constraint, and as an instance constraint, but a type synonym cannot be made for it. Not sure if this really counts as a bug ("just switch on ImpredicativeTypes"), but I think it's worth discussing. I prefer to keep ImpredicativeTypes switched off, but if something can be a constraint, shouldn't I be able to create a type synonym of it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 04:05:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 04:05:54 -0000 Subject: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics In-Reply-To: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> References: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> Message-ID: <058.cc2651c2dca522ed0023c8f7b32fe78e@haskell.org> #1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------------+------------------------------------- Reporter: neil | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cg059 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edmundnoble): Now that there's a testcase verifying that the original YHC code is currently compiled correctly, should I assume that the issue of the compiler not distinguishing different `error`s in different `case` branches is fixed? Testing the example given in comment9 shows it still behaves the same way, which seems to imply that it isn't and the YHC code working is a fluke. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 04:27:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 04:27:07 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression Message-ID: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The credit goes to wuzzeb for originally discovering this bug [https://www.reddit.com/r/haskell/comments/ad9a7k/strictdata_typefamilies_and_ghc_86/ here]. I've minimized their test case slightly below: {{{#!hs {-# LANGUAGE StrictData #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family T newtype instance T = MkT Int deriving Eq }}} With optimization enabled, this program compiles with GHC 8.0.2 through 8.4.4, but not with 8.6.3 or HEAD: {{{ $ /opt/ghc/8.4.4/bin/ghc -fforce-recomp -O Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:39: error: • Couldn't match a lifted type with an unlifted type arising from the coercion of the method ‘==’ from type ‘GHC.Prim.Int# -> GHC.Prim.Int# -> Bool’ to type ‘T -> T -> Bool’ • When deriving the instance for (Eq T) | 6 | newtype instance T = MkT Int deriving Eq | ^^ }}} Based on the error message, it appears as if GHC mistakenly believes that the representation type of the `T` instance is `Int#`, rather than `Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 05:13:23 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 05:13:23 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.33255429529525fe804eb261c95e0f4f@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Replying to [comment:4 simonpj]: >The reason things go wrong is that in the RHS of hte rule in `GHC.Int` you really want to apply the rule `"round/Double->Int"` in `GHC.Float`, but perhaps it is not imported by `GHC.Int`? > > Anyway, probably the best solution here is to rewrite the rule in `GHC.Int` to > {{{ > "round/Double->Int64" > round = (fromIntegral :: Int -> Int64) . GHC.Float.roundDoubleInt > }}} > (And maybe the same for `fromIntegral`?) It seems wrong to me to manually expand rules that already exist. Seems very unprincipled and easy to miss other existing cases: I'm confident {{{Int64}}} isn't the only offender, there are similar rules all around. I'm happy to submit a patch as proposed but I wonder if there isn't a better way to ensure the relevant rules are in scope together... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 07:27:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 07:27:32 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.5887076a6e092b74901f6aa8d8af596c@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:4 simonpj]: > * Rules are applied to the RHS of other rules, if the phases allow; this seems reasonable. After all, that's what will happen whenever the rule is applied. Hmm, this doesn't appear to be true in general. It looks like user-defined rules are never applied to the RHS of other rules. Only built-in rules are. I checked this by compiling the following module: {{{#!hs module Foo where import qualified GHC.List as List foo, bar:: Int foo = 0 bar = 0 baz :: [Int] baz = [] {-# RULES "foo" foo = 1 #-} {-# RULES "bar/foo" bar = foo #-} -- the "foo" rule doesn't fire {-# RULES "baz" baz = List.concat [] #-} -- the "concat" rule from GHC.List doesn't fire }}} Here is what I think is the relevant code https://gitlab.haskell.org/ghc/ghc/blob/9ea8dcea3e5ba96808ef91028e0efde9d31f7272/compiler/simplCore/Simplify.hs#L3558. The rule RHS is simplified under `rule_env`, which has the `sm_rules` field set to `False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 08:00:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 08:00:05 -0000 Subject: [GHC] #16126: Make -threaded the default In-Reply-To: <049.6bccecc4e766ed4d66f82d70ee136719@haskell.org> References: <049.6bccecc4e766ed4d66f82d70ee136719@haskell.org> Message-ID: <064.88d84538b0539153d9a78f22081c28a5@haskell.org> #16126: Make -threaded the default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 08:45:24 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 08:45:24 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.3281aecc6e74a28d599338861c298cfb@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > We would like to have functions that check whether an `Int#` is a valid > tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): > > {{{ > isTrue# :: Int# -> Bool > isTrue# 1# = True > isTrue# _ = False > > isFalse# :: Int# -> Bool > isFalse# 0# = True > isFalse# _ = False > }}} > > We could use them with comparison primops like this: > > {{{ > f :: Int# -> Int > f x | isTrue# (x ># 0#) = I# x > | otherwise = -(I# x) > }}} > > `isTrue#` is optimized away at the Core level: > > {{{ > A.f = > \ (x_aqM :: GHC.Prim.Int#) -> > case GHC.Prim.># x_aqM 0 of _ { > __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); > 1 -> GHC.Types.I# x_aqM > } > }}} > > but the code genrator produces very bad Cmm code, because it pushes heap > checks into case alternatives: > > {{{ > {offset > cFd: // stack check > if ((Sp + -16) < SpLim) goto cFr; else goto cFs; > cFr: // not enough place on the stack, call GC > R2 = R2; > R1 = A.f_closure; > call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; > cFs: // scrutinize (x ># 0#) > _sEU::I64 = R2; > _sEV::I64 = %MO_S_Gt_W64(R2, 0); > if (_sEV::I64 != 1) goto cFg; else goto cFo; > cFg: // False branch > Hp = Hp + 16; > if (Hp > HpLim) goto cFy; else goto cFx; > cFy: // not enough heap, call GC > HpAlloc = 16; > I64[Sp - 16] = cFf; > R1 = _sEV::I64; > I64[Sp - 8] = _sEU::I64; > Sp = Sp - 16; > call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: > 8; > cFf: // re-do the False branch > _sEU::I64 = I64[Sp + 8]; > Sp = Sp + 16; > _sEV::I64 = R1; > goto cFg; > cFx: // RHS of False branch > I64[Hp - 8] = GHC.Types.I#_con_info; > I64[Hp] = -_sEU::I64; > R1 = Hp - 7; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > cFo: // True branch > Hp = Hp + 16; > if (Hp > HpLim) goto cFv; else goto cFu; > cFv: // not enough heap, call GC > HpAlloc = 16; > I64[Sp - 16] = cFn; > R1 = _sEV::I64; > I64[Sp - 8] = _sEU::I64; > Sp = Sp - 16; > call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: > 8; > cFn: // re-do the True branch > _sEU::I64 = I64[Sp + 8]; > Sp = Sp + 16; > _sEV::I64 = R1; > goto cFo; > cFu: // RHS of True branch > I64[Hp - 8] = GHC.Types.I#_con_info; > I64[Hp] = _sEU::I64; > R1 = Hp - 7; > call (P64[Sp])(R1) args: 8, res: 0, upd: 8; > } > }}} > > This results in average 2.5% increase in binary size. By contrast, if we > use `tagToEnum#` instead of `isTrue#` heap check will be placed before > `case` expression and the code will be significantly shorter (this is > done by a special case-on-bool optimization in the code generator - see > #8317). What we would like to do here is: > > 1. compile case alternatives without placing heap checks inside them > 2. each compiled alternative should return amount of heap it needs to > allocate > 3. code generator inspects amounts of heap needed by each alternative > and either adds heap checks in alternatives or puts a single check before > the case expression. > > Getting this right might be a bit tricky. > 1. if all branches allocate some heap then we can just put a common > heap check before the case. Note that we must allocate the higgest amount > required by any of the alternatives and then alternatives that use less > heap must retract the heap pointer accordingly. > 2. if we have two alternatives, one of which allocates heap and the > other does not, we should place the heap check only in the alternative > that allocates the stack. This will solve #1498. > 3. it is not clear to me what to do if we have combination of the above > (more than one branch that allocates heap and at least one branch that > does not). If we place heap check before the `case` expression we lose > optimization of recursive functions and face the problem described in > #1498. If we push heap checks into branches that allocate heap then we > get code duplication, i.e. the problem that we're addressing in this > ticket. I guess the only way to make correct decission here is to try > different aproaches and measure their performance. > > This ticket is mentioned > [http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails on > this wiki page] and in the source code in Note [Optimizing isTrue#] in > ghc-prim. Once this ticket is resolved we need to update these places > accordingly. New description: We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} We could use them with comparison primops like this: {{{ f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} `isTrue#` is optimized away at the Core level: {{{ A.f = \ (x_aqM :: GHC.Prim.Int#) -> case GHC.Prim.># x_aqM 0 of _ { __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); 1 -> GHC.Types.I# x_aqM } }}} but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives: {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is: 1. compile case alternatives without placing heap checks inside them 2. each compiled alternative should return amount of heap it needs to allocate 3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression. Getting this right might be a bit tricky. 1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly. 2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498. 3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance. This ticket is mentioned * [http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails on this wiki page] * in the source code in Note [Optimizing isTrue#] in ghc-prim. * In `Simplify.hs`, `Note [Optimising tagToEnum#]` Once this ticket is resolved we need to update these places accordingly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 09:04:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 09:04:30 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.f895fff17d2ad5814c8561f331acfc66@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It looks like user-defined rules are never applied to the RHS of other rules Hmm. You are right. See `Note [Simplifying rules]` in `SimplUtils`. So rules are switched off on both RHS and LHS of rules. But as noted above, built-in rules are not switched off. In `Rules.hs` I see {{{ matchRule dflags rule_env _is_active fn args _rough_args (BuiltinRule { ru_try = match_fn }) -- Built-in rules can't be switched off, it seems = case match_fn dflags rule_env fn args of Nothing -> Nothing Just expr -> Just expr }}} This seems wrong. If we are going to switch off rules we should switch them all off. We could just add {{{ matchRule dflags rule_env _is_active fn args _rough_args (BuiltinRule { ru_try = match_fn }) | not (is_active AlwaysActive) -- Built-in rules are always active, but = Nothing -- sometimes we switch off rules altogether -- E.g. see SimplUtils.updModeForRules | otherwise = case match_fn dflags rule_env fn args of Nothing -> Nothing Just expr -> Just expr }}} That still leaves the issue that two rules, a built-in one and a user- specified one, can be simultaneously active. Which will win? Well, it turns out that that user specified one does. See this code in `Rules.hs` {{{ isMoreSpecific :: CoreRule -> CoreRule -> Bool -- This tests if one rule is more specific than another -- We take the view that a BuiltinRule is less specific than -- anything else, because we want user-define rules to "win" -- In particular, class ops have a built-in rule, but we -- any user-specific rules to win -- eg (Trac #4397) -- truncate :: (RealFrac a, Integral b) => a -> b -- {-# RULES "truncate/Double->Int" truncate = double2Int #-} -- double2Int :: Double -> Int -- We want the specific RULE to beat the built-in class-op rule }}} I don't think this behaviour is documented in the user manual -- it should be. That would fix this ticket. But in a rather delicate way: we rely on /not/ applying a built-in rule R1 to the RHS of another rule R2, in case when R2 fires there is a user-defined rule R3 that will beat R1. However, ignore built-in rules for the moment. The `isMoreSpecfic` code above makes rule S1 "beat" rule S2 if S1 is more specific -- that is, if S1's LHS is a substitution instance of S2's. (We should document this behaviour too.) So consider {{{ {-# RULES "S1" forall x. f [x] = blah1 "S2" forall y. f [Just y] = blah2 "S3" forall z. h z = f [z] #-} If we applied rules to the RHS of S3, only S1 would apply. But if didn't (as happens now), and we had a term `h (Just 3)`, we'd rewrite it with S3 to `f [Just 3]`, and now both S1 and S2 apply, and S2 would win. So this is a distinct reason, which we should add to `Note [Simplifying rules]`, for not applying rules to the RHS of rules. Would anyone like to write a patch for these fixes? * Make the above change to `matchRule` * Document the overlap behaviour of RULES in the user manual * Add the above reasoning to `Note [Simplifying rules]` Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 09:06:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 09:06:55 -0000 Subject: [GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` In-Reply-To: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> References: <047.8324e9cc4b3ebe99f9f5457f1fda52a7@haskell.org> Message-ID: <062.73ca044f2d1d51e4ec658671519effa0@haskell.org> #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round` -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Finally, I still think it'd be clearer (i.e. easier to reason about what will ultimately happen) to call `roundDoubleInt` directly in the rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 09:29:45 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 09:29:45 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.409ec6089eaa0e36724daf8f90679d9b@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Who knows. This is a nice use-case for ASSERT(). Actally I think a little eyeballing would do the job. > Simplifier. But the mechanism by which it picks up the level variables is still a riddle for me. It may well be "float let from let" (see the ICFP paper on let-floating). Consider {{{ let x = let y = blah in y : ys in blah2 }}} The simplifier float the `let y`, to give {{{ let y = blah in let x = y : ys in blah2 }}} This is much better because it exposes the fact that `x` is a cons. The test is done by `doFloatFromRhs` in `Simplify.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 09:47:12 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 09:47:12 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.51c19970c22efcf36ba7bee5f715aed4@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you didn't have that `{-# NOINLINE a #-}`, then the `IND_STATIC` would point directly to `a1_closure`, and would be correctly tagged. And in general, absent `{-# NOINLINE #-}` directives, I believe that all that cases your patch optimises would be optimised by the simplifier to get the code you want. So that seems to narrow the scope of the optimisation considerably: * You save code-size on many (or perhaps all?) `IND_STATIC` closures. * You save entering any such `IND_STATIC`s that are marked `NOINLINE`. So yes, it's an improvement, but I wonder whether it's worth the extra code and maintenance burden? I'm thinking of someone looking at this code in 5 yrs time. Do you think it is? Thanks for doing this -- I'm not criticising, just trying to understand with precision what is and is not happening. Clarity is good! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 10:25:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 10:25:10 -0000 Subject: [GHC] #16142: RTS statistic TASKS is not documented Message-ID: <045.a9e173bedfb2bca4348b6a232b1cc7c6@haskell.org> #16142: RTS statistic TASKS is not documented -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS has a output TASKS which is not documented under http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html #rts-options-to-produce-runtime-statistics / http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_control.html #rts-options-to-produce-runtime-statistics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 10:45:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 10:45:22 -0000 Subject: [GHC] #16142: RTS statistic TASKS is not documented In-Reply-To: <045.a9e173bedfb2bca4348b6a232b1cc7c6@haskell.org> References: <045.a9e173bedfb2bca4348b6a232b1cc7c6@haskell.org> Message-ID: <060.8c18fc6b3cf69236e0988b9f6a055c6c@haskell.org> #16142: RTS statistic TASKS is not documented -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by adamse: Old description: > The RTS has a output TASKS which is not documented under > http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html > #rts-options-to-produce-runtime-statistics / > http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_control.html > #rts-options-to-produce-runtime-statistics New description: The RTS has a output TASKS which is not documented: http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html #rts-options-to-produce-runtime-statistics http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_control.html #rts-options-to-produce-runtime-statistics -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 10:48:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 10:48:14 -0000 Subject: [GHC] #16142: RTS statistic TASKS is not documented In-Reply-To: <045.a9e173bedfb2bca4348b6a232b1cc7c6@haskell.org> References: <045.a9e173bedfb2bca4348b6a232b1cc7c6@haskell.org> Message-ID: <060.d5fcb4ec90345316cc2f41285aec210a@haskell.org> #16142: RTS statistic TASKS is not documented -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by adamse: Old description: > The RTS has a output TASKS which is not documented: > > http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html > #rts-options-to-produce-runtime-statistics > > http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_control.html > #rts-options-to-produce-runtime-statistics New description: The RTS has a output TASKS which is not documented: http://downloads.haskell.org/~ghc/master/users-guide/runtime_control.html #rts-options-to-produce-runtime-statistics http://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/runtime_control.html #rts-options-to-produce-runtime-statistics Sample of current output: {{{ ... TASKS: 7199 (1 bound, 33 peak workers (7198 total), using -N4) SPARKS: 0(0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.004s ( 0.003s elapsed) MUT time 369355.862s (36159.798s elapsed) GC time 2539.600s (219.713s elapsed) EXIT time 0.025s ( 0.028s elapsed) Total time 371895.491s (36379.541s elapsed) Alloc rate 7,192,933 bytes per MUT second Productivity 99.3% of total user, 99.4% of total elapsed }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 11:02:04 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 11:02:04 -0000 Subject: [GHC] #16143: Some cost centre stacks are not registered via registerCcsList() Message-ID: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> #16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15508 I observe that some closures have incorrect CCS field. To be able to catch this problem as early as possible I implemented a simple check: {{{ static void checkClosureProfSanity(const StgClosure *p) { StgProfHeader prof_hdr = p->header.prof; CostCentreStack *ccs = prof_hdr.ccs; // For now just make sure the CCS is a registered CCS and not a pointer to // some random heap closure (happened before, see #15508). for (CostCentreStack *ccs_ = CCS_LIST; ccs_; ccs_ = ccs_->prevStack) { if (ccs == ccs_) { return; } } barf("CCS for closure %p is not registered: %p", (void*)p, (void*)ccs); } }}} I call this on all closures before and after a GC. This assumes that all cost centre stacks are registered via `registerCcsList()`, however this currently does not hold. I was able to find two cases: - `base_GHCziIOziHandleziFD_CAFs_cc_ccs` is never registered (there are probably a few CCSs per module like this which are never registered) - None of the dynamically allocated CCSs are registered. My question is: am I misunderstanding how the CCS registry (`CCS_LIST`) is supposed to be used? I thought all CCSs should really be in that list, because the list is used when reporting. Not registering a CCS means not reporting it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 11:55:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 11:55:21 -0000 Subject: [GHC] #16144: GHC with valid license on windows Message-ID: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> #16144: GHC with valid license on windows -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: incorrect | Operating System: Unknown/Multiple license on windows | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* since for these version with the right licenses (in particular using integer-simple) are available. Could you please make the windows version of GHC with BSD3 / MIT license available on the next release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 11:55:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 11:55:40 -0000 Subject: [GHC] #16144: GHC with valid license on windows In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.915f3fd41c98c32aab5216a9787a8248@haskell.org> #16144: GHC with valid license on windows -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: incorrect | license on windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pjljvdlaar): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 13:31:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 13:31:28 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.c54b2608f2bd8665f183402a1d1fcdd3@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, this appears to be my fault, as this regression was introduced in commit eb680f2c0a365b12f9b867da6bb10e9ab4b328e0 (`Fix newtype instance GADTs`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 13:31:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 13:31:52 -0000 Subject: [GHC] #16144: GHC with valid license on windows In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.69bab9f968bee74cc69eb6f42f31a4a1@haskell.org> #16144: GHC with valid license on windows -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: incorrect | license on windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by pjljvdlaar: Old description: > Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* > since for these version with the right licenses (in particular using > integer-simple) are available. > Could you please make the windows version of GHC with BSD3 / MIT license > available on the next release? New description: Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* since for these version, no GHC installer with the right licenses (in particular using integer-simple) are available. Could you please make the windows version of GHC with BSD3 / MIT license available on the next release? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 13:32:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 13:32:10 -0000 Subject: [GHC] #16144: GHC with valid license on windows In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.6a82ddbe291c007d71378fc29f7534c2@haskell.org> #16144: GHC with valid license on windows -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: incorrect | license on windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by pjljvdlaar: Old description: > Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* > since for these version, no GHC installer with the right licenses (in > particular using integer-simple) are available. > Could you please make the windows version of GHC with BSD3 / MIT license > available on the next release? New description: Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* since for these versions, no GHC installer with the right licenses (in particular using integer-simple) are available. Could you please make the windows version of GHC with BSD3 / MIT license available on the next release? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 14:27:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 14:27:40 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.cd647104b7c140ca16f822cc5def8d93@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It turns out you don't need `deriving` to notice something afoot with this program. Even if you just have this: {{{#!hs {-# LANGUAGE StrictData #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family T newtype instance T = MkT Int }}} And compile this with `-O -dcore-lint`, it blows up: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -O -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Tidy Core *** : warning: In a case alternative: (I# dt_aXp :: Int#) Type of case alternatives not the same as the annotation on case: Actual type: R:T Annotation on case: T Alt Rhs: dt_aXp `cast` (Sym (N:R:T[0]) :: Int# ~R# R:T) *** Offending Program *** $WMkT [InlPrag=INLINE[2]] :: Int -> T [GblId[DataConWrapper], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (dt_aXo [Occ=Once!] :: Int) -> (case dt_aXo of { I# dt_aXp [Occ=Once] -> dt_aXp `cast` (Sym (N:R:T[0]) :: Int# ~R# R:T) }) `cast` (Sym (D:R:T0[0]) :: R:T ~R# T)}] $WMkT = \ (dt_aXo [Occ=Once!] :: Int) -> (case dt_aXo of { I# dt_aXp [Occ=Once] -> dt_aXp `cast` (Sym (N:R:T[0]) :: Int# ~R# R:T) }) `cast` (Sym (D:R:T0[0]) :: R:T ~R# T) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 14:34:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 14:34:58 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.04cb4fa39a06c1326e922606195b2a51@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is an interesting question. When written to the left of an `=>`, the parentheses delimit a list that is inlined. However, in a type synonym, you're really building a tuple. So GHC's behavior here is just a manifestation of this internal design... but the design shouldn't leak this way. I would classify it as a bug, yes. It's unclear to me how to solve it, though, especially because GHC struggles to tell constraint tuples apart from normal ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 14:53:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 14:53:42 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.94fcefa0338189a502655086363d5e45@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => QuantifiedConstraints, ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 14:54:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 14:54:20 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.faf43a1ece5da6138a352d7237b5aa2c@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 14:59:25 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 14:59:25 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.4568a4efe513e2d7ebf6fa9370fbe8a9@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T15798{a,b,c} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/48 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => rename/should_compile/T15798{a,b,c} * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/48 * resolution: => fixed * milestone: => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/c121e33f9b039acf2ac6939af8bfafe593560039 c121e33f9b039acf2ac6939af8bfafe593560039]: {{{ Author: chessai Date: Wed Dec 26 12:12:37 2018 -0500 Add -Wmissing-deriving-strategies Warn users when -XDerivingStrategies is enabled but not used, at each potential use site. add -Wmissing-deriving-strategies Reviewers: bgamari, RyanGlScott Subscribers: andrewthad, rwbarton, carter GHC Trac Issues: #15798 Differential Revision: https://phabricator.haskell.org/D5451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 15:49:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 15:49:39 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies Message-ID: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- F.hs: {{{#!hs module F where import G main = g }}} G.hs: {{{#!hs module G where g = print () }}} Running: {{{ $ runghc --version runghc 8.6.2 $ runghc -- -fobject-code -osuf=hs.o F *** Exception: G.hs.o: getModificationTime:getFileStatus: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 15:50:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 15:50:19 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies In-Reply-To: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> References: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> Message-ID: <060.ba53cd11b02e372be4717514148da1b0@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by adamse: Old description: > F.hs: > {{{#!hs > module F where > > import G > > main = g > }}} > > G.hs: > {{{#!hs > module G where > > g = print () > }}} > > Running: > {{{ > $ runghc --version > runghc 8.6.2 > $ runghc -- -fobject-code -osuf=hs.o F > *** Exception: G.hs.o: getModificationTime:getFileStatus: does not exist > (No such file or directory) > }}} New description: F.hs: {{{#!hs module F where import G main = g }}} G.hs: {{{#!hs module G where g = print () }}} Running: {{{ $ runghc --version runghc 8.6.2 $ runghc -- -fobject-code -osuf=hs.o F *** Exception: G.hs.o: getModificationTime:getFileStatus: does not exist (No such file or directory) $ ls F.hs G.hi G.hs G.hs.hs.o }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 15:52:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 15:52:59 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies In-Reply-To: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> References: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> Message-ID: <060.77a7ba25f8e3149a42f3a4e05ecc0da8@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by malcolmw): Also, if you change the -osuf flag to e.g. `-osuf=hs.hs.o`, then the compiler generates instead an object file called `G.hs.hs.hs.hs.o` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 15:59:25 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 15:59:25 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies In-Reply-To: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> References: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> Message-ID: <060.5bc16580f11fd19b103723a5c61e986b@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): Do things work as expected if the `-osuf` flag is omitted altogether ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 16:00:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 16:00:31 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies In-Reply-To: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> References: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> Message-ID: <060.1efef01ba544874e4baa80fab9387803@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): Yes, without -osuf the example works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 16:43:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 16:43:29 -0000 Subject: [GHC] #16145: runghc with -fobject-code and -osuf fails to find dependencies In-Reply-To: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> References: <045.1e98d4e6d1bf93a8ff840562b0e648f6@haskell.org> Message-ID: <060.447812bb0a5d033e142ea7c712137913@haskell.org> #16145: runghc with -fobject-code and -osuf fails to find dependencies -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): It seems that putting {{{hs.}}} anywhere breaks: {{{ $ runghc -- -fobject-code -osuf=xxxhs.o F *** Exception: G.xxxhs.o: getModificationTime:getFileStatus: does not exist (No such file or directory) }}} But a osuf without hs. works fine: {{{ $ runghc -- -fobject-code -osuf=xxxhso F () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:02:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:02:21 -0000 Subject: [GHC] #16133: TH can sneak in TypeApplications without enabling the extension In-Reply-To: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> References: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> Message-ID: <065.3fe196e125946e5b227e6153910c0054@haskell.org> #16133: TH can sneak in TypeApplications without enabling the extension -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T16133 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/77 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T16133 * status: patch => closed * resolution: => fixed Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/bbd58fb5f029b632e2d8977518723feee0737ba7 bbd58fb5f029b632e2d8977518723feee0737ba7]: {{{ Author: Ryan Scott Date: Sat Jan 5 12:40:39 2019 -0500 Fix #16133 by checking for TypeApplications in rnExpr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:15:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:15:01 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.4b1547a4ac164c96cc00abd83ead3eb5@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Reverted big PE patch in `ghc-8.6` with c68270119b7f215a6d7f30fc020856fa94056dc3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:15:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:15:56 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.68874711a542f4cfdbc6f38459898d77@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.8.1 Comment: I'm going to punt on merging this back to `ghc-8.6`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:17:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:17:09 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.9ff3a1a4296d0e06d1c17343e7a9a824@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by bgamari): Is this really needed on `ghc-8.6`? ef57272e28f5047599249ae457609a079d8aebef doesn't apply cleanly as-is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:24:25 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:24:25 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.18241faee1d7c565d6c761a47142fe77@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm starting to think that this is actually an old bug with `StrictData`, since the following program (which uses a plain old newtype, not a data family) also breaks Core Lint in a similar fashion with GHC 8.4.4 or later: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StrictData #-} module Bug where newtype T a b where MkT :: forall b a. Int -> T a b }}} {{{ $ /opt/ghc/8.4.4/bin/ghc -O -dcore-lint Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Tidy Core *** : warning: In a case alternative: (I# dt_aXx :: Int#) Type of case alternatives not the same as the annotation on case: Actual type: T a_atk b_atj Annotation on case: T b_atj a_atk Alt Rhs: dt_aXx `cast` (Sym (N:T[0] _P _P) :: (Int# :: TYPE 'IntRep) ~R# (T a_atk b_atj :: *)) *** Offending Program *** $WMkT [InlPrag=INLINE[2]] :: forall b a. Int -> T a b [GblId[DataConWrapper], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (@ b_atj) (@ a_atk) (dt_aXw [Occ=Once!] :: Int) -> case dt_aXw of { I# dt_aXx [Occ=Once] -> dt_aXx `cast` (Sym (N:T[0] _P _P) :: (Int# :: TYPE 'IntRep) ~R# (T a_atk b_atj :: *)) }}] $WMkT = \ (@ b_atj) (@ a_atk) (dt_aXw [Occ=Once!] :: Int) -> case dt_aXw of { I# dt_aXx [Occ=Once] -> dt_aXx `cast` (Sym (N:T[0] _P _P) :: (Int# :: TYPE 'IntRep) ~R# (T a_atk b_atj :: *)) } }}} The issue appears to involve newtypes with wrappers in general. (The reason why the original program only started breaking with GHC 8.6 is because commit eb680f2c0a365b12f9b867da6bb10e9ab4b328e0 changed GHC's treatment of newtype instances so that they would have wrappers where they didn't before.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:26:24 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:26:24 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.6ae712c6f5977f030f08f9e9e4e4f867@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The mention of `Int#` has me wondering: is GHC trying to unpack the `Int` field of `MkT`? If so, I would surely think that that's incorrect, since the idea of unpacking a newtype seems bogus, especially since GHC rejects this program: {{{ λ> newtype T = MkT {-# UNPACK #-} !Int :1:13: error: • A newtype constructor cannot have a strictness annotation, but ‘MkT’ does • In the definition of data constructor ‘MkT’ In the newtype declaration for ‘T’ }}} Perhaps the implementation of `StrictData` misses this fact, however. I'll check the code to see if that is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 17:51:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 17:51:22 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.98a5e60d7153893fa51c542a539298de@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 18:00:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 18:00:06 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.e840dce1dde3bf612f278c421245cfd6@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): My hunch appears to be correct. The [https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/basicTypes/MkId.hs#L784-798 dataConSrcToImplBang] function is what is responsible for making decisions about strictness/unpacking w.r.t. `StrictData`: {{{#!hs -- | Unpack/Strictness decisions from source module dataConSrcToImplBang :: DynFlags -> FamInstEnvs -> Type -> HsSrcBang -> HsImplBang dataConSrcToImplBang dflags fam_envs arg_ty (HsSrcBang ann unpk NoSrcStrict) | xopt LangExt.StrictData dflags -- StrictData => strict field = dataConSrcToImplBang dflags fam_envs arg_ty (HsSrcBang ann unpk SrcStrict) | otherwise -- no StrictData => lazy field = HsLazy }}} Notice that this does not take into account whether the `Type` of the field belongs to a newtype or not, so this will indeed unpack the field of a newtype with `StrictData` + `-O` enabled. Yikes. One could fix this by propagating information about whether we're in a newtype or not to `dataConSrcToImplBang`. But then again, should we really even need to call `dataConSrcToImplBang` if we're dealing with a newtype? `dataConSrcToImplBang` is internal to `MkId` and only has one call site, so I'm inclined to just avoid invoking it at its call site, like so: {{{#!diff diff --git a/compiler/basicTypes/MkId.hs b/compiler/basicTypes/MkId.hs index 5a6f1fbf96..fa3d6785b7 100644 --- a/compiler/basicTypes/MkId.hs +++ b/compiler/basicTypes/MkId.hs @@ -637,11 +637,15 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con -- Because we are going to apply the eq_spec args manually in the -- wrapper - arg_ibangs = - case mb_bangs of - Nothing -> zipWith (dataConSrcToImplBang dflags fam_envs) - orig_arg_tys orig_bangs - Just bangs -> bangs + new_tycon = isNewTyCon tycon + arg_ibangs + | new_tycon + = nOfThem (length orig_arg_tys) HsLazy + | otherwise + = case mb_bangs of + Nothing -> zipWith (dataConSrcToImplBang dflags fam_envs) + orig_arg_tys orig_bangs + Just bangs -> bangs (rep_tys_w_strs, wrappers) = unzip (zipWith dataConArgRep all_arg_tys (ev_ibangs ++ arg_ibangs)) @@ -650,7 +654,7 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con (rep_tys, rep_strs) = unzip (concat rep_tys_w_strs) wrapper_reqd = - (not (isNewTyCon tycon) + (not new_tycon -- (Most) newtypes have only a worker, with the exception -- of some newtypes written with GADT syntax. See below. && (any isBanged (ev_ibangs ++ arg_ibangs) }}} This certainly fixes the two programs in this ticket, and it passes the rest of the testsuite. Does this sound like the right approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 18:12:36 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 18:12:36 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.759e12e9e3e9292f7ed9c9e773def890@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Unfortunately with 8.6.3 I'm getting: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "powerpc64-unknown-freebsd-gcc" --gcc-flag -Wall --gcc-flag -Werror=unused-but-set-variable --gcc-flag -Wno-error=inline --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist- derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "" --target-os "freebsd" deriveConstants: : readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory) libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory gmake[1]: *** [includes/ghc.mk:193: includes/dist- derivedconstants/header/DerivedConstants.h] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 18:14:44 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 18:14:44 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.1664d2ee5f7e64402b001d9cd9dc40ea@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: 15376 Related Tickets: #15376 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Visible kind application adds another layer of screwball-ery to the mix: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Kind class Cat (cat :: k -> k -> Type) instance Cat (->) newtype Fun1 a b = Fun1 (a -> b) deriving (Cat @k) }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -ddump-deriv -fprint-explicit-kinds GHCi, version 8.7.20190105: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance Bug.Cat @* Bug.Fun1 where Derived type family instances: Ok, one module loaded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 18:45:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 18:45:56 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.04389996953736898fe6141df50781bf@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by trommler): I will prepare a patch based on the 8.6 branch and push it to gitlab. If you decide to not merge the patch after all it is at least there for packagers to include in their packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 19:19:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 19:19:15 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs Message-ID: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose we have {{{#!hs data G a where G1 :: G Char G2 :: G Bool }}} If I now write {{{#!hs foo x = case x of G1 -> 'z' G2 -> True }}} I rightly get an error around untouchable variables. If I add the type signature {{{#!hs foo :: G a -> a }}} all is well again. So far, so good. Now, I write {{{#!hs foo :: forall a. G a -> a foo x = ((case x of G1 -> 'z' G2 -> True) :: _) }}} and I get those untouchable errors again. Untouchable-variable errors usually arise when there are multiple possible answers to the type inference problem. Yet, that isn't the case here: `_` must stand for `a`. Solution: mumble mumble bidirectional type inference mumble mumble. Part of the problem comes from Note [Partial expression signatures] in TcExpr, which states {{{ here is a guiding principile e :: ty should behave like let x :: ty x = e in x }}} Indeed, if we behave like that, the untouchable-variable errors are to be expected. But I also think that it would be a nice principle to say that `:: _` is always a no-op. This is not an idle nice-to-have: if we fix this, `singletons` will continue to work with GHC. Right now, it doesn't: https://github.com/goldfirere/singletons/issues/357 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 19:54:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 19:54:58 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.565e6e4eb558eece15cca9045ec62868@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 21:00:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 21:00:55 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.86a1ff2b6c4821f3150cba3eb7ef8956@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.4 Component: Runtime System | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: Ty bgamari :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 21:09:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 21:09:35 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.4f68c7e99ee6414d38ebc1a2e612bc71@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 21:23:36 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 21:23:36 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) In-Reply-To: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> References: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> Message-ID: <066.03648117d6f752c45cf78f3fcb26b567@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: Resolution: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This is fixed (rather accidentally) by the implementation of the `UnliftedNewtypes` proposal, which is not yet merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 7 23:08:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Jan 2019 23:08:55 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) In-Reply-To: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> References: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> Message-ID: <066.85d37be23cdb61f6501e74891324f091@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: Resolution: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4777 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 00:13:22 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 00:13:22 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.04ea3de6a6c6566f13e4aac165e3acda@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not obvious what to do here. Consider {{{ f :: Int -> Int -> Int f x = (...blah...) :: forall a. a->a }}} Here the expression signature insists that `(..blah..)` has type `forall a. a->a` which is ''more general than'' the `Int -> Int` imposed by the signature for `f`. Now imagine a partial version of this: {{{ f :: Int -> Int -> Int f x = (...blah...) :: forall a. a -> _ }}} The same thing applies. Because the partial signature may be more general than the expected type from "outside", it's hard to take advantage of the latter until we've worked out what the fleshed-out partial signature is (ie. in this case perhaps `forall a. a->a`). Only then can we instantiate it to see if it is more general than `Int -> Int`. So while `(e :: _)` may be a no-op, that is not true of other partial type signatures. Short of making it a magic, ad-hoc special case, I'm not sure how to do better. Perhaps one could make a special case when the partial signature had no quantification. But it sounds smelly to me. Why not just remove the `:: _`? It's not doing anything useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 01:29:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 01:29:56 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.287e4c732ec6309e2f11826c16d5a613@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Assuming that we don't wish to accept the original program, I think we can blame `rnClsInstDecl`. [https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/rename/RnSource.hs#L646-657 This] is the first part of that function: {{{#!hs rnClsInstDecl :: ClsInstDecl GhcPs -> RnM (ClsInstDecl GhcRn, FreeVars) rnClsInstDecl (ClsInstDecl { cid_poly_ty = inst_ty, cid_binds = mbinds , cid_sigs = uprags, cid_tyfam_insts = ats , cid_overlap_mode = oflag , cid_datafam_insts = adts }) = do { (inst_ty', inst_fvs) <- rnLHsInstType (text "an instance declaration") inst_ty ; let (ktv_names, _, head_ty') = splitLHsInstDeclTy inst_ty' ; let cls = case hsTyGetAppHead_maybe head_ty' of Nothing -> mkUnboundName (mkTcOccFS (fsLit "")) Just (dL->L _ cls) -> cls -- rnLHsInstType has added an error message -- if hsTyGetAppHead_maybe fails }}} Since we're using `splitLHsInstDeclTy` to decompose `inst_ty`, if we feed it something sketchy like `Eq a => Eq a => Eq (T a)` as input, then `head_ty'` will be `Eq a => Eq (T a)` (which is not headed by a class, leading to havoc later on). Notice that that comment at the bottom assumes that `rnLHsInstType` throws an error message if `inst_ty` is malformed. But in commit 1c062b794bf71a329f65813ce7b72fe2bd3935f0, we have: {{{#!diff diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs index 2305a04..b2dafb2 100644 (file) --- a/compiler/rename/RnTypes.hs +++ b/compiler/rename/RnTypes.hs @@ -326,20 +326,8 @@ rnImplicitBndrs bind_free_tvs doc rnLHsInstType :: SDoc -> LHsSigType GhcPs -> RnM (LHsSigType GhcRn, FreeVars) -- Rename the type in an instance or standalone deriving decl -- The 'doc_str' is "an instance declaration" or "a VECTORISE pragma" -rnLHsInstType doc_str inst_ty - | Just cls <- getLHsInstDeclClass_maybe inst_ty - , isTcOcc (rdrNameOcc (unLoc cls)) - -- The guards check that the instance type looks like - -- blah => C ty1 .. tyn - = do { let full_doc = doc_str <+> text "for" <+> quotes (ppr cls) - ; rnHsSigType (GenericCtx full_doc) inst_ty } - - | otherwise -- The instance is malformed, but we'd still like - -- to make progress rather than failing outright, so - -- we report more errors. So we rename it anyway. - = do { addErrAt (getLoc (hsSigType inst_ty)) $ - text "Malformed instance:" <+> ppr inst_ty - ; rnHsSigType (GenericCtx doc_str) inst_ty } +-- Do not try to decompose the inst_ty in case it is malformed +rnLHsInstType doc inst_ty = rnHsSigType (GenericCtx doc) inst_ty mk_implicit_bndrs :: [Name] -- implicitly bound -> a -- payload }}} Notice that `rnLHsInstType` no longer errors if given malformed input! So `rnClsInstDecl` charges on under the false pretense that `rnLHsInstType` succeeded. Perhaps the right thing to do would be to move the old validity check from `rnLHsInstType` to `rnClsInstDecl`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 02:45:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 02:45:03 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.914d148f15299a7f27770b3717d2fffe@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The real use case isn't `:: _` -- it's `:: Sing @_ (Something Big && Obnoxious)`. The right value for the `_` is being pushed down, but it can't be inferred from the expression in the signature. The signature is needed in some scenarios... not actually the one that's causing trouble, though. The problem is that I think it will be impossible for `singletons` to tell the difference between scenarios where it's needed and those where it isn't, so we need it not to interfere. The signature in question indeed does no quantification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 05:39:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 05:39:02 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS Message-ID: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 System | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I run this script on macOS, after about 15 minutes, a `ghc-pkg` process will deadlock. {{{#!sh #!/usr/bin/env bash out=`pwd`/testing-package-db rm -rf $out cabal update cabal install random mkdir -p $out ghc-pkg init $out/package.conf.d while true; do ghc-pkg --package-db $HOME/.ghc/x86_64-darwin-8.6.3/package.conf.d dump | ghc-pkg --force --package-db $out/package.conf.d register - done }}} Output from `sw_vers`: {{{ ProductName: Mac OS X ProductVersion: 10.12.6 BuildVersion: 16G29 }}} This GHC build comes from the latest nixpkgs-18.09. I have also attached a nix file to build test scripts. We noticed that if we edited the ghc-pkg binary to link with the threaded RTS, then we could not reproduce the deadlock (after running the test script for 24 hours). Attached is the output from `/usr/bin/sample` for the stuck process, and the `otool -L ghc-pkg` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 05:39:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 05:39:28 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.5678bee7cbeac5523d047b4c1d788e0a@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rvl): * Attachment "sample.txt" added. Output from /usr/bin/sample -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 05:39:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 05:39:47 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.73720fc302798b2cf80c081f244a8943@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rvl): * Attachment "otool.txt" added. Output from otool -L ghc-pkg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 05:40:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 05:40:27 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.4ca871a7bb512a76c42a8d44adef95ed@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rvl): * Attachment "devops-1202.nix" added. Nix recipe to build scripts to reproduce the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 05:49:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 05:49:27 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.08f874525115ac0be305f10e50be0a37@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 08:38:24 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 08:38:24 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.d53041de556f982ee825d155a7558e50@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I suppose we could have a different typing rule for the case where there is no quantification. I'm not very keen on this, because it changes behaviour in a subtle way, and just adding an unrelated quantifier to the partial signature would completely change its typing rule. It's user-facing, so perhaps GHC-proposal-worthy? The relevant function is `tcExprSig`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 09:43:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 09:43:38 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.8283c72e7d3987916fd5d0f5268cd0ee@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Notice that rnLHsInstType no longer errors if given malformed input! I can't for the life of me figure out WHY we made that change. There is only one call to `rnLHsInstType`, and it makes sense * For `rnLHsInstType` to error on a malformed instance * To use the same function `getLHsInstDeclClass_maybe` as is already used for this purpose in `RnNames.getLocalNonValBinders` We need to discover the class in the renamer so that we have the right "parent" for lookups. So can we just put the check back inot `rnLHsInstType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:02:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:02:04 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.68ce52dd55cc11b4b929d4d907e180a2@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Comment (by simonpj): Good catch. I think you have the right approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:16:42 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:16:42 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.542638a0fc97403d733f3bcd20ed716d@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually it might not be too hard. The error message comes from `TcValidity`, by which time we know for sure what is a constraint and what is an ordinary tuple. Maybe, with `QuantifiedConstraints` we should simply accept polytypes at the top level of a constraint tuple. Indeed, in types like `forall a. (pred1, pred2) => glah` we already do, when checking `pred1`, `pred2`: {{{ check_pred_ty :: TidyEnv -> DynFlags -> UserTypeCtxt -> PredType -> TcM () -- Check the validity of a predicate in a signature -- See Note [Validity checking for constraints] check_pred_ty env dflags ctxt pred = do { check_type env SigmaCtxt rank pred ; check_pred_help False env dflags ctxt pred } where rank | xopt LangExt.QuantifiedConstraints dflags = ArbitraryRank | otherwise = constraintMonoType }}} But we currently do not do this for the RHS of type synonyms of kind `Constraint`. Moreover, we you can see, `check_pred_ty` also does some extra validity checks on predicates, using `check_pred_help`. (These checks are not described in a Note but probably should be.) Example: require `TypeFamilies` for `t1 ~ t2`. We should probably do these exact same checks for the RHS of constraint synonyms. Proposal: * In `checkValidType`, if the kind of the type is `Constraint`, then use `check_pred_ty` rather than `check_type`. Do you agree? Would you like to try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:52:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:52:16 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.bec31023f497fab8ed81ddc3c4b68912@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is more fall-out from the `Constraint` vs `Type` distinction. The kinding rules are {{{ ty : TYPE rep `a` is not free in rep (FORALL1) ----------------------- forall a. ty : TYPE rep ty : Constraint (FORALL2) ------------------------- forall a. ty : Constraint }}} How do we know which of these rules to use? Currently we do it by looking at the "expected kind", using `FORALL2` is the expected kind is `Constraint`. That's why it works if you give a kind signature. You could say "infer the kind of the body type, and use that to choose"; but that's vulnerable to exactly what constraints are solved when. Or perhaps you could do both. It's very uncomfortable having two different rules. I've often wondered about defining {{{ type Constraint = TYPE ConstraintRep }}} in which case one rule would do. Richard thinks this won't work but I forget why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:56:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:56:01 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type Message-ID: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An enduring infelicity in GHC’s type inference is the treatment of tuples. Consider, this from `RaeJobTalk`: {{{ type family F c sch where F _ '[] = (() :: Constraint) F c (col ': cols) = (c Int, F c cols) }}} When kind-checking `F`, we initially give it a return kind of kappa, a unification variable. Suppose we kind-check the second equation first. Then what kind of tuple is it, a constraint tuple, or an ordinary type tuple. We must unify kappa with `Type` or `Constraint` respectively – and they are different kinds. How can we choose which? Currently we have the following unsatisfactory ruse: 1. Look at the “expected kind”. If we kind-check the second equation first we learn nothing from that 2. Infer kinds for all of the elements of the type. Again in this case we learn nothing. 3. If we still know nothing, arbitrarily pick Type This is horrible. If we kind check the first equation first, step 1 will discover Constraint, and kind checking succeeds. But if we put the equations in the other order, kind checking fails. Ugh! Another example with exactly the same cause is #16139. What to do? I can only think of three approaches: A. Add a pseudo constraint `(TC kappa)` meaning “kappa must eventually turn out to be either `Type` or `Constraint`”. When generalising, default to `Type`. B. Same, but by having a special sort of TauTv, a TCTv, which can only unify with Type or Constraint. Again, do not generalise over such type variables. C. Define {{{ type Type = TYPE (LiftedRep T) type Constraint = TYPE (LiftedRep C) }}} So now we can unify `kappa` with `(TYPE (LiftedRep zeta))` where `zeta` is a unification variable that we must eventually unify with `T` or `C`. Of these, (C) seems most principled, but somehow over-elaborate for our purposes. And the others also seem to be rather too much work to solve a simple, local problem. ------------- For reference, here are the current kinding rules {{{ t1 : TYPE rep1 t2 : TYPE rep2 (FUN) ---------------- t1 -> t2 : Type t1 : Constraint t2 : TYPE rep (PRED1) ---------------- t1 => t2 : Type t1 : Constraint t2 : Constraint (PRED2) --------------------- t1 => t2 : Constraint ty : TYPE rep `a` is not free in rep (FORALL1) ----------------------- forall a. ty : TYPE rep ty : Constraint (FORALL2) ------------------------- forall a. ty : Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:57:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:57:38 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.e9c9c5962f2568458ee6d09733578bf9@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard responds: This has come up before, of course. I've always had an affinity for choice (A). It's easy to describe, even to users, and I think it will lead to nice error messages (which can special-case printing unsolved TC constraints). I don't think it would take all that much code. (C) doesn't actually work, tempting though it may be. Consider ( {{{ f :: forall (r :: RuntimeRep) (a :: TYPE r). a -> () }}} Don't worry about levity-polymorphism restrictions in binding positions, as that's not the issue here. The question is: does f take 1 visible argument or 0? The answer depends on the choice of r (under plan C), because r might be LiftedRep C. So have no way of reliably instantiating f's type at an occurrence and are thus dead in the water. Plan D: {{{ data TC = T | C TYPE :: RuntimeRep -> TC -> Type }}} That is, make the T/C distinction totally orthogonal to representation, and simply disallow any quantification over a type whose kind has a variable in the TC position. This has the nice side effect of allowing unlifted constraints (e.g., an unboxed implicit parameter or a strict dictionary). But it has the significant drawback of polluting the type of `(->)`, which would now be {{{ (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (tc1 :: TC) (tc2 :: TC). TYPE r1 tc1 -> TYPE r2 tc2 -> TYPE LiftedRep tc2 }}} Indeed, we have considered this route before, [https://github.com/ghc- proposals/ghc- proposals/blob/0506dd68fefa26f56dd8e377d4c9d34bf241252f/proposals/0000 -constraint-vs-type.rst here]. The main drawback I see from that abandoned approach in the proposal is that it banned newtype-classes. I don't think we have a satisfactory way (yet) of eliminating newtype-classes while keeping, e.g., reflection working. (This matters: singletons uses the reflection trick to change exponentially-slow processes to linear ones.) Summing up, I see two ways forward: - Simon's (A) - (D) above, including banning newtype-classes and coming up with a new way for the reflection trick to work. Simon's (B) would work, but it seems strictly inferior to (A), simply because a new TyVar flavor is a more obscure approach to getting the behavior we would see in (A), whereas (A) uses an abstraction (a class- like constraint) that everyone knows and loves. Between these two approaches, (A) is at least an order of magnitude easier. So I vote for that. :) I do believe, though, that we'll have to do (D) eventually, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 10:59:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 10:59:27 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.6ba5b84474ee62a8e6cdd8015fa427ff@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > (C) doesn't work Are you sure? I was not expecting any quantification whatsoever over the T/C thing. You say "don't worry about levity polymorphism", but the example you give is explicitly ruled out by our lev-poly story. Can you give an example that would be allowed by lev-poly but would give rise to instantiation problems? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:00:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:00:10 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.eb1e809fba864a17b821d7a668aa37bd@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #16148, which I've created to gather these awkward type/constraint issues together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:01:05 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:01:05 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.5110e880820afb5743aa539a16abf850@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16139 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #16139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:32:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:32:03 -0000 Subject: [GHC] #16135: Panic with ExistentialQuantification and ApplicativeDo In-Reply-To: <053.2647af571b23876e29228e6722df209d@haskell.org> References: <053.2647af571b23876e29228e6722df209d@haskell.org> Message-ID: <068.0c2c95bcd6453ecf3294a55dc3afee59@haskell.org> #16135: Panic with ExistentialQuantification and ApplicativeDo -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the root cause of this is that the applicative-do stuff just doesn't work well with existentials. See [https://www.microsoft.com/en- us/research/publication/desugaring-haskells-do-notation-into-applicative- operations/ the paper]. The desugaring in Fig 5 really only works if the binder of the patterns don't include existentials. To me that says: * GHC should check for this and complain if necessary. Not crash! * Someone might like to think about whether it'd be possible to accommodate existentials. Simon M: this is your territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:51:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:51:46 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.5aa0b7b4f13af229f7dae1f0b72cc5b7@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The spirit of this proposal sounds nice, but there's a couple things that I'm worried about: * This proposal suggests accepting polytypes in all types of kind `Constraint`. Would that mean that the following would be accepted? {{{#!hs f :: (?x :: Proxy (forall a. Eq a => Eq (f a) :: Constraint)) => Int; f = 42 }}} Unlike in the original example, `Proxy (forall a. Eq a => Eq (f a) :: Constraint)` appears to be truly impredicative. * Let's suppose you define `type F2 f = (Functor f, forall a. Eq (f a))` (which would now be accepted under this proposal without needing `ImpredicativeTypes`) and later try to define `g :: Proxy (F2 Maybe); g = Proxy`. Would //that// count as impredicative? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:53:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:53:40 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.c2d67883f6cf58798ae8e973da10ec32@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #13742, #16139 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #16139 => #11621, #11715, #13742, #16139 Comment: See also: * #11621 * #11715 * #13742 Which cover issues in the same space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:54:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:54:19 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.81fc222be0a4abcfbbd57eec24c67e41@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #13742, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11621, #11715, #13742, #16148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:55:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:55:21 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.bed137b326c4b2d8e73eb1a9a913178b@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742, | Differential Rev(s): #16139, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11715, #13742 => #11715, #13742, #16139, #16148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:55:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:55:37 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.c77af65978596eb0ba03dac29efbab9b@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know what is happening. In `A.hs-boot` (which has `-XPolyKinds`) we have {{{ T :: forall k. k -> Type }}} Then in `B.hs-boot` we have {{{ method :: forall i x. C i => T @Type i -> x }}} When compiling `A.hs` (no `-XPolyKinds`) we get {{{ T :: Type -> Type }}} Now, when we deserialise that imported singature for `method` we construct the ill-kinded type `T @Type i`. Result, disaster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:55:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:55:40 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.0cab0eef948baf2e89416c15fea5ffcd@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #13742, | Differential Rev(s): Phab:D3316 #16139, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11621, #13742 => #11621, #13742, #16139, #16148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 11:55:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 11:55:48 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.f01c18de4b85b53228ce73cf78f0c9d5@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #16139, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11621, #11715 => #11621, #11715, #16139, #16148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:00:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:00:10 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.dec4133dc37ce00f73cc873158f4474c@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What to do? The real problem is that if `A.hs` defines a type `T` differently than `A.hs-boot`, then anything imported into `A` whose type or kind mentions `T` is going to be ill-kinded. So I think the Right Thing is * Immediately after typechecking a type/class declaration `T`, check if there is a hs-boot file definition for it; if so, compare, and fail if there is a mis-match. Currently the hs-boot file comparison happens all at the end, so this would require a little re-plumbing. But before doing that, let's check that everyone agrees. (Now that we know the cause, it should be easy to make an even simpler repro case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:03:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:03:18 -0000 Subject: [GHC] #16128: Pattern match checker should shortcut on simple cases In-Reply-To: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> References: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> Message-ID: <058.bc97303c590fb28adf1de5dc5d86b7e7@haskell.org> #16128: Pattern match checker should shortcut on simple cases -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It seems to me that in a case like this, GHC should be able to just check that there are no duplicate strings I agree that such a simple use-case should not make the pattern match checker have a heart attack. The pattern-match checker badly needs someone to love it. It's basically in quite good shape, with a published paper to explain how it works. But it suffers from having no active maintainer -- except the ever-energetic Ryan S, who has many other things on his radar. Who would like to do this? Many people would thank you! See [wiki:PatternMatchCheck] for a list of open tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:08:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:08:27 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.d304a17fb5bea8ed5bd3f8d19616a310@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This proposal suggests accepting polytypes in all types of kind Constraint. Would that mean that the following would be accepted? No, it would not. Under the `Proxy` we switch off the arbitrary-rank thing. Try it today! (The proposals doesn't change the behaviour of type signatures. > Would that count as impredicative? I think we have decided that behaviour never changes when type synonyms are expanded; and have already gone to some trouble to make this so (in a recent ticket). So yes it would be impredicative, and would (or should) be caught. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:10:13 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:10:13 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.1af4c640c459ee2f7ea7ba1ba4b8c1c1@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Some history on this ticket: you committed 1c062b794bf71a329f65813ce7b72fe2bd3935f0 after I complained (in https://phabricator.haskell.org/D4383#122346) that `rnLHsInstType` was overly complicated due to the previous validity checking. You responded (in https://phabricator.haskell.org/D4383#122347) that it was safe to remove this validity check from `rnLHsInstType` altogether, as `checkValidInstance` apparently performs the same check. I'm not sure if that was true at one point in time, but it certainly doesn't appear to be true as of GHC 8.6. As you say, we could certainly put the check back into `rnLHsInstType`. But to be honest, that might cause an overall regression in error message quality, judging from the changes to error messages (generally for the better) in commit 1c062b794bf71a329f65813ce7b72fe2bd3935f0. Another option would be to re-investigate `checkValidInstance`, confirm whether or not it checks for instances of the form `Eq a => Eq a => Eq (T a)`, and if not, add a check for it and see if it fires before we get this `Class ‘Eq’ does not have a method ‘==’` nonsense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:15:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:15:48 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.496eea54e603d05dbfa59047b50d36d1@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Another option would be to re-investigate checkValidInstance I don't think so. What I missed before is that ''the renamer needs to know'' which class is involved so it has the right "parent" for lookups. You can see this in the call to `getLHsInstDeclClass_maybe` in `RnNames.getLocalNonValBinders`. And it is also the cause of this ticket, because the instance got past the renamer only by remaming `(==)` not to the `(==)` from the `Eq` class, but to a new unrelated top-level binder. Yikes. I think putting up with marginally less-cool errors may be a price we have to pay. Rather than "mal-formed" we could say {{{ Class instances must be of the form context => C ty1 .. tyn where C is a class }}} or something more positive than "mal-formed". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:18:07 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:18:07 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.1b6f0837ae9dac453b4064022c49a493@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Alright, if you're happy with that error message, then so am I. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 12:32:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 12:32:53 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.9e41558039f231d1f010057f45feb616@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michaelpj): I think we're also observing this. I think this is not the intended behaviour. Looking at the documentation of `thNameToGhcName` it says: "Qualified or unqualified TH names will be dynamically bound to names in the module being compiled, if possible." My interpretation of this was: if you can import the name qualified in the module being compiled when the core plugin triggers, then the name lookup should succeed. This seems to no longer be true. I can also confirm that adding (unused) imports for the modules whose names are being accessed makes the lookup work again. In our case the plugin *is* registered via a separate package and we're still seeing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 13:02:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 13:02:49 -0000 Subject: [GHC] #16149: GHC for NetBSD Message-ID: <042.ec25b766da631cfe6646ad0852f629a2@haskell.org> #16149: GHC for NetBSD ---------------------------------------+--------------------------------- Reporter: gh1 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: NetBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- I tried to build GHC for NetBSD from source but it faild and it took a long time. So, may I ask for: a binaries for NetBSD or published manual how to build GHC from source for NetBSD ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 13:36:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 13:36:32 -0000 Subject: [GHC] #16134: Continuous integration on FreeBSD In-Reply-To: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> References: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> Message-ID: <061.4bc58cdfc147cb54ac66f20d4fa0a750@haskell.org> #16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arrowd): * cc: arrowd@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 13:57:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 13:57:53 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.b639ae965a23c7b913e5dc58fc670ba5@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Phab:D5471, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/90 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D5471 => Phab:D5471, https://gitlab.haskell.org/ghc/ghc/merge_requests/90 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:10:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:10:28 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.03ddcdf2c81cc425cbbcca691e3d26ea@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:12 pkubaj]: > Unfortunately with 8.6.3 I'm getting: Do you have some more context for me so I can reproduce the error? What was in your `build.mk` and what was your `./configure` command line? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:11:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:11:45 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.31de85e99d75ad8a59da83214333991f@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Could this happen without the `-XPolyKinds` disparity? It sounds like "yes". If that's the case, then I agree with your plan. If the only way this happens is the `-XPolyKinds` disparity, then I would want to think about this other option: Brutally require that an .hs-boot file and its regular-module counterpart have exactly the same set of extensions enabled. This could be checked very early on, halting with an appropriate error message before ever looking at declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:12:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:12:10 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.d469e9deab3f7749b8f420aab057ec16@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): I am going to dump here the differences between 8.6.3-created libs and HEAD's libs, w.r.t. exported nullary symbols: {{{ $ nm /home/pkoeckri/.stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/libHSbase-4.12.0.0.a | grep evtRead U base_GHCziEventziInternal_evtRead_closure U base_GHCziEventziInternal_evtRead_closure 0000000000000000 D base_GHCziEventziInternal_evtRead_closure U base_GHCziEventziInternal_evtRead_closure U base_GHCziEventziInternal_evtRead_closure U base_GHCziEventziInternal_evtRead_closure }}} (`lib/ghc-8.4.4/base-4.11.1.0/libHSbase-4.11.1.0.a` is identical to above.) {{{ $ nm _build/stage1/lib/x86_64-linux- ghc-8.7.20190106/base-4.12.0.0/libHSbase-4.12.0.0.a | grep evtRe U base_GHCziEventziInternal_evtRead1_closure U base_GHCziEventziInternal_evtRead1_closure 0000000000000290 D base_GHCziEventziInternal_evtRead1_closure 00000000000002a0 D base_GHCziEventziInternal_evtRead_closure U base_GHCziEventziInternal_evtRead1_closure U base_GHCziEventziInternal_evtRead1_closure U base_GHCziEventziInternal_evtRead1_closure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:14:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:14:21 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.020842b6a23a4c024d85fc54381e1328@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/92 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/92 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:15:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:15:26 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.48cb38301aaabf19d66f8d115e8358aa@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Replying to [comment:13 trommler]: > Replying to [comment:12 pkubaj]: > > Unfortunately with 8.6.3 I'm getting: > Do you have some more context for me so I can reproduce the error? > What was in your `build.mk` and what was your `./configure` command line? I think I fixed it (although build is still going). The error can be seen in the compiler flags (--nm-program ""). I needed to add nm for crosscompiling to powerpc64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:16:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:16:15 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.9ee1903fb05e79aff8b111a7cc90293b@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I believe it could happens simply if the T in `A.hs-boot` differs from the `T` in `A.hs`; eg differently-kinded arguments. But I have not tried to cause crashes/Lint errors by doing this; that'd be a good thing to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:17:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:17:41 -0000 Subject: [GHC] #16139: GHC confused about type synonym kind with QuantifiedConstraints In-Reply-To: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> References: <053.efbce9e0e7c48e25ab56a5da17540049@haskell.org> Message-ID: <068.3497f7673c00e866f3ebfdc1e7bd87a1@haskell.org> #16139: GHC confused about type synonym kind with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #13742, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): `type Constraint = TYPE ConstraintRep` won't work because levity- polymorphic functions would have an unknowable number of explicit arguments. Take something like `absX :: forall (r :: RuntimeRep) (a :: TYPE r). NumX a => a -> a`. (This is possible if `NumX` is levity polymorphic.) How many explicit arguments does `absX` take? It depends on the choice of `r`, because what looks like the one explicit argument becomes implicit if `r` is `ConstraintRep`. Even worse, this function would ''return'' a constraint, something we don't currently allow for normal functions. What would work is `type Constraint = TYPE LiftedRep YesIsConstraint`, where we index `TYPE` by yet another flag. That's the most principled answer here, but it seems like using a sledgehammer to tap in a nail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:19:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:19:41 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.a875c55ce96924f589bf3019965b7abc@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That's what I thought -- the kind disparity could be brought about in a number of ways. Yes, it seems the only real way to fix this is more eager consistency checking between .hs-boot files and .hs files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:23:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:23:27 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.8014cadf08b15a3c3743997403df3857@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of completeness, here is a variant of the program suite in comment:7 that exhibits the same panic by providing different numbers of arguments to `T` instead of using `PolyKinds`: {{{#!hs -- A.hs module A where import {-# SOURCE #-} B data T i = MkT i thisPanics :: x thisPanics = method (MkT 'a') }}} {{{#!hs -- A.hs-boot module A where data T i1 i2 }}} {{{#!hs -- B.hs module B where import A class C i where method :: T i -> x }}} {{{#!hs -- B.hs-boot module B where import {-# SOURCE #-} A class C i where method :: T i a -> x }}} ----- {{{ $ /opt/ghc/8.6.3/bin/ghc A.hs [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B[boot] ( B.hs-boot, B.o-boot ) [3 of 4] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): piResultTys1 * [a_aYd[tau:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:34:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:34:48 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.1a56af948ab4a5de550ee8d53ef042df@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I think it should also be easy to provoke with only one one hs- boot file; and with no classes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 15:45:57 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 15:45:57 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.62894e5d15d29eadaab6b9c44bdd825e@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried your suggestion in comment:3, and unfortunately, impredicativity //does// sneak in, as the following is accepted: {{{#!hs {-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, QuantifiedConstraints, FlexibleInstances, UndecidableInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ImplicitParams #-} module Bug where import Data.Kind import Data.Proxy type F1 (f :: * -> *) = forall a. Eq (f a) class (Functor f, F1 f) => C f instance (Functor f, F1 f) => C f type F2 f = (Functor f, F1 f) f :: (Proxy (F2 f) ~ Proxy (F2 f)) => Int f = 42 }}} On the other hand, the following variant: {{{#!hs g :: (Proxy (Functor f, forall a. Eq (f a)) ~ Proxy (Functor f, forall a. Eq (f a))) => Int g = 42 }}} Is rejected as impredicative. (It's possible that this is just #16059 manifesting in a different way, though.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 16:06:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 16:06:48 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.fcabd71c200f1ad480dd07a181266d6e@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): As a workaround you can run ghci with `-fobject-code`, and for haddock add the `--optghc="-fobject-code"` (you won't need the TemplateHaskell langauge pragma anymore either). Anyhow, this is a regression I introduced when improving/fixing the recompilation logic: https://github.com/ghc/ghc/commit/52065e95c6df89d0048c6e3f35d6cc26ce8246f9 So to determine whether we need to recompile a module we need to track its "inputs", which includes the plugins the the module was compiled with. We decided to use the binary objects, `.so/.a` for packaged plugins, `.o` for local plugins, because they can only give false positives to determine whether the functionality of the plugin changes (`.hi` files can give false negatives). I guess I need to rethink how to handle local plugins... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 16:49:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 16:49:23 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.309e28b1abde4fe853330dced1ed7227@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/69 -------------------------------------+------------------------------------- Changes (by adamse): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/69 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 17:11:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 17:11:39 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.cb0d16140e9b795441ade7f82e18d897@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's possible that this is just #16059 manifesting in a different way, though. Sounds likely to me. And we have a plan for #16059, in comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 17:21:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 17:21:51 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.4341ee38c9a9ca0b26fbe8190a833098@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #13742, #16139 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > You say "don't worry about levity polymorphism", but the example you give is explicitly ruled out by our lev-poly story Ah, that's not true: see [https://www.microsoft.com/en- us/research/publication/levity-polymorphism/ Section 7.3 of the levity- polymorphism paper], where we discuss functions like {{{ absX :: forall (r :: RuntimeRep) (a :: TYPE r). NumX a => a -> a }}} where `NumX :: forall (r :: RuntimeRep). TYPE r -> Constraint` is levity- polymorphic. Here we allow `absX` to have an arrow `a -> a` with a levity-polymorphic argument; it's just ''term binders'' that can't have levity-polymorphic types. Another point is that messing with TYPE etc affects the entire compiler. A major merit of plan (A) is that it affects the type inference engine only and is then gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 17:35:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 17:35:48 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer Message-ID: <045.67366c6314679071e780eb66600c5b99@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.4.4 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our local environment allows running Haskell programs under ThreadSanitizer. Even though the GHC runtime and compiled Haskell code are not instrumented, ThreadSanitizer still found a bug through interceptor instrumentation. I'll try to minimize the case and create a reproducer, but in case somebody wants to look at this with just the report, here it is (mildly massaged to remove irrelevant addresses): {{{ ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 1 at 0x55986a3e4f10 by thread T1: #0 pthread_mutex_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1245:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 Previous atomic read of size 1 at 0x55986a3e4f10 by main thread: #0 pthread_mutex_lock llvm/compiler- rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:4097:3 #1 startTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:184:5 #2 exitTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:206 #3 __libc_start_main (libc.so.6+0x38bbc) Location is global 'mutex' of size 40 at 0x55986a3e4f10 Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 in itimer_thread_func ================== ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 8 at 0x55986a3e4ee0 by thread T1: #0 pthread_cond_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1216:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 Previous read of size 8 at 0x55986a3e4ee0 by main thread (mutexes: write M146179626018688784): #0 pthread_cond_signal llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1202:3 #1 signalCondition vendor_src/v8_4_4/rts/posix/OSThreads.c:111:11 #2 __libc_start_main (libc.so.6+0x38bbc) Location is global 'start_cond' of size 48 at 0x55986a3e4ee0 Mutex M146179626018688784 is already destroyed. Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 in itimer_thread_func ================== ThreadSanitizer: reported 2 warnings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 18:09:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 18:09:16 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI In-Reply-To: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> References: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> Message-ID: <064.95b42c62de15e681128d58dafc558eed@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 18:29:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 18:29:37 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.fa10f5bdeac7fc8dfd29d89f517753b4@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:14 pkubaj]: > The error can be seen in the compiler flags (--nm-program ""). I needed to add nm for crosscompiling to powerpc64. Could that be a bug in the build system? I would expect `nm` to be set to `-nm` automatically. Could you create a new ticket if there is a problem with the build system? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 18:37:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 18:37:50 -0000 Subject: [GHC] #16151: GHC 8.6 build failure on ARM Message-ID: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> #16151: GHC 8.6 build failure on ARM --------------------------------+---------------------------------------- Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- I'm attempting to build the ghc-8.6 branch on ARM linux. I have GHC 8.2.2 and LLVM 6.0.1 installed. My only build.mk change is to set BuildFlavour=quick I've made it as far as "final phase" where I get the following failure: {{{ ===--- building final phase /usr/bin/make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -optc-D NOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghc154171_0/ghc_8.s: Assembler messages: /tmp/ghc154171_0/ghc_8.s:32:0: error: Error: selected processor does not support `movw r7,:lower16:stg_enter_info' in ARM mode | 32 | movw r7, :lower16:stg_enter_info | ^ /tmp/ghc154171_0/ghc_8.s:33:0: error: Error: selected processor does not support `movt r7,:upper16:stg_enter_info' in ARM mode | 33 | movt r7, :upper16:stg_enter_info | ^ /tmp/ghc154171_0/ghc_8.s:231:0: error: Error: selected processor does not support `movw r2,#32512' in ARM mode | 231 | movw r2, #32512 | ^ /tmp/ghc154171_0/ghc_8.s:233:0: error: Error: selected processor does not support `movt r2,#640' in ARM mode | 233 | movt r2, #640 | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 18:40:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 18:40:38 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.52cb85d49d3f198839c07470e68d7c89@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): It's set up automatically. But build should fail at configure with explicit info that nm is needed. I managed to build it, now I need to test it on POWER. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 18:59:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 18:59:44 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.4a286dcd063dda785ffabf197fcaf40e@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Phab:D5137 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): As suspected, the float-out thing is happening in the wild. See the (entire) mail thread: https://mail.haskell.org/pipermail/ghc- devs/2019-January/016835.html. Maybe we should sometime look into ''deduplicating static data''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:03:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:03:56 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.74fb7d5efaa4c45099c57216284cfd22@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:07:00 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:07:00 -0000 Subject: [GHC] #16148: Better type inference for Constraint vs Type In-Reply-To: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> References: <046.9e0f6c21c489722f800c073dba4ecc03@haskell.org> Message-ID: <061.f6ec4447057d2c07f1d497b246634768@haskell.org> #16148: Better type inference for Constraint vs Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715, | Differential Rev(s): #13742, #16139 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I fully agree with comment:5. Especially the last bit, about affecting only the type inference engine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:17:55 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:17:55 -0000 Subject: [GHC] #5622: Out of memory in such a simple case In-Reply-To: <043.1942018e0cd3dd83326ebf941251c97d@haskell.org> References: <043.1942018e0cd3dd83326ebf941251c97d@haskell.org> Message-ID: <058.482f5d8ce295b17e483e77119c3d43b7@haskell.org> #5622: Out of memory in such a simple case -------------------------------------+------------------------------------- Reporter: quux | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kirelagin): For all those people from the future who’ll try to figure out what is going on here, a small clarification: the issue is not with type-inference itself, you can easily use `:t` in GHCi and it will infer the type instantly. The problem is that in Core type applications are spelled out explicitly, so the ''terms'' end up being exponentially large. {{{ foo4 :: forall a_alK. a_alK -> a_alK [GblId, Str=DmdType] foo4 = \ (@ a_am0) -> id @ (((a_am0 -> a_am0) -> a_am0 -> a_am0) -> (a_am0 -> a_am0) -> a_am0 -> a_am0) (id @ ((a_am0 -> a_am0) -> a_am0 -> a_am0)) (id @ (a_am0 -> a_am0)) (id @ a_am0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:24:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:24:49 -0000 Subject: [GHC] #16152: Core lint error from PartialTypeSignatures Message-ID: <051.267e28704195fd373b6028bcf6ae94c9@haskell.org> #16152: Core lint error from PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Options_GHC -dcore-lint #-} top :: forall f. _ top = undefined where x :: forall a. f a x = undefined }}} causes Core lint errors: {{{ $ ~/../inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 922_bug.hs GHCi, version 8.7.20181230: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 922_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the type ‘forall (f :: k_a1z6 -> *) w. w’ @ k_a1z6 is out of scope *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) top :: forall (f :: k_a1z6 -> *) w. w [LclIdX] top = \ (@ (f_a2BY :: k_a1z6 -> *)) (@ w_a2BZ) -> (\ (@ k_a1z6) (@ (f_a1yV :: k_a1z6 -> *)) (@ w_a1yN) -> let { $dIP_a2BO :: ?callStack::CallStack [LclId] $dIP_a2BO = emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in let { $dIP_a2BD :: HasCallStack [LclId] $dIP_a2BD = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "922_bug.hs"#) (I# 8#) (I# 7#) (I# 8#) (I# 16#)) ($dIP_a2BO `cast` (N:IP[0] <"callStack">_N _N :: (?callStack::CallStack) ~R# CallStack))) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in letrec { top_a1yW :: w_a1yN [LclId] top_a1yW = letrec { x_a1yv :: forall (a :: k_a1z6). f_a1yV a [LclId] x_a1yv = \ (@ (a_a1zd :: k_a1z6)) -> let { $dIP_a2BP :: ?callStack::CallStack [LclId] $dIP_a2BP = emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in let { $dIP_a2Bz :: HasCallStack [LclId] $dIP_a2Bz = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "922_bug.hs"#) (I# 11#) (I# 7#) (I# 11#) (I# 16#)) ($dIP_a2BP `cast` (N:IP[0] <"callStack">_N _N :: (?callStack::CallStack) ~R# CallStack))) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in break<0>() undefined @ 'LiftedRep @ (f_a1yV a_a1zd) $dIP_a2Bz; } in break<1>() undefined @ 'LiftedRep @ w_a1yN $dIP_a2BD; } in top_a1yW) @ Any @ Any @ w_a2BZ end Rec } *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:28:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:28:39 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.0fe6afaa1f962dbc947a6585bd342f46@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Why does quantification enter into it, now that I think of it? Let's look at some typing rules, where `<=` denotes checking and `=>` denotes inference in the bidirectional type system. I use `t` to denote a type (no wildcards) and `p` to denote a partial type (zero or more wildcards). {{{ e <= t ------------ Sig (e : t) => t e => t1 t1 <: t2 -------- Infer e <= t2 }}} These rules govern what happens when an expression with a complete type signature `(e : t1)` is checked against a type `t2`. Because there is no `<=` rule for the `(e : t1)` form, we use the Infer rule to switch into synthesis mode. Since we have `t1` as the type signature, we synthesize type `t1` for `(e : t1)`. Then, we check to make sure that `t1` is a subtype of `t2`. (Reminder: `t1` is a subtype of `t2` iff there is a computationally free way to convert a value of type `t1` to a value of type `t2`. Example: `forall a. a -> a` is a subtype of `Int -> Int` because we can instantiate a value of type `forall a. a -> a` with `Int` with no runtime cost.) Currently, this is the rule for an expression with a partial type signature: {{{ e <~~ p => t ------------ PartialSig (e : p) => t }}} where `e <~~ p => t` means that checking `e` against partial signature `p` results in a type `t`. This is done by GHC's `simplifyInfer`. I propose adding a new rule to the system: {{{ p <: t2 => p2 e <~~ p2 => t t <: t2 ------------- PartialSigCheck (e : p) <= t2 }}} where `p <: t2 => p2` means: 1. Check whether `p` is a subtype of `t2`. 2. During this check, we might have to choose values for wildcards in `p`. 3. `p2` is `p`, but with the wildcards zonked to have the values discovered in the subtype check. Note that `p2` might actually have no wildcards left. Regardless, we will use the `e <~~ p2 => t` (`simplifyInfer`) operation, as checking against a partial type signature is really quite different than checking against a complete type signature, and we wouldn't want unifications with the pushed-down type to chane this. Naturally, we have to do another subtype check, just to make sure that the type after `simplifyInfer` is suitable. (It's possible that we can prove that if `p <: t2 => p2` and `e <~~ p2 => t`, then `t <: t2`. Indeed, that would be desirable. But I'm not sure right now if this would be true.) I ''think'' that would solve our problem. And it seems to make GHC strictly more expressive. And it would seem to be "what the user would expect", making use of information manifestly available (but, today, ignored). This would require writing a new subtyping check `p <: t2 => p2`. The implementation of subtyping in GHC is somewhat laborious, but it's not a particularly complicated judgment. It's unclear how much code-sharing this new form would have with the existing one, given the different way that partial types are represented internally. I agree that this is a GHC proposal. However, the consequences of this are subtle and hard to predict, so I want to have some debate here before going there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:31:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:31:08 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.474beed4230bfd94977f7ab41d6ec3bb@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Phab:D5137 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:19 bgamari]: > For the record, this patch put up resistance in the form of validation issues when I tried to merge it before 8.6.1. I can try again for 8.6.2. We need milestones e.g. for 8.6.4 :-) Also, which kind of failures did you get? SEGVs? May we have a re-trial with the 8.6 branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:32:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:32:28 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.bfbc99db980d266a32d267efe845f001@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_fail/T16013 Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Phab:D5471, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/90 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => ghci/should_fail/T16013 * resolution: => fixed * milestone: => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/6b70cf611e5ddc475edaa54b893d20990699ddb8 6b70cf611e5ddc475edaa54b893d20990699ddb8]: {{{ commit 6b70cf611e5ddc475edaa54b893d20990699ddb8 Author: Ryan Scott Date: Tue Jan 8 07:37:18 2019 -0500 Be pickier about unsaturated synonyms in :kind Summary: We currently permit any and all uses of unsaturated type synonyms and type families in GHCi's `:kind` command, which allows strange interactions like this one: ``` > :set -XTypeFamilies -XPolyKinds > type family Id (a :: k) > type instance Id a = a > type Foo x = Maybe > :kind! Id Foo ``` This is probably a stretch too far, so this patch moves to disallow unsaturated synonyms that aren't at the top level (we still want to allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt` with an additional `Bool` field to indicate if we are at the outermost level of the type being passed to `:kind` or not. See `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the full story. Test Plan: make test TEST=T16013 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: simonpj, goldfire, rwbarton, carter GHC Trac Issues: #16013 Differential Revision: https://phabricator.haskell.org/D5471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:34:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:34:10 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.962d9ed2958af0c527a8abd9f9475bed@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089, #16013 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #12089 => #12089, #16013 Comment: Note that we opted to disallow unsaturated type synonyms/families in GHCi when not at the top level in commit [https://gitlab.haskell.org/ghc/ghc/commit/6b70cf611e5ddc475edaa54b893d20990699ddb8 6b70cf611e5ddc475edaa54b893d20990699ddb8]: {{{ commit 6b70cf611e5ddc475edaa54b893d20990699ddb8 Author: Ryan Scott Date: Tue Jan 8 07:37:18 2019 -0500 Be pickier about unsaturated synonyms in :kind Summary: We currently permit any and all uses of unsaturated type synonyms and type families in GHCi's `:kind` command, which allows strange interactions like this one: ``` > :set -XTypeFamilies -XPolyKinds > type family Id (a :: k) > type instance Id a = a > type Foo x = Maybe > :kind! Id Foo ``` This is probably a stretch too far, so this patch moves to disallow unsaturated synonyms that aren't at the top level (we still want to allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt` with an additional `Bool` field to indicate if we are at the outermost level of the type being passed to `:kind` or not. See `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the full story. Test Plan: make test TEST=T16013 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: simonpj, goldfire, rwbarton, carter GHC Trac Issues: #16013 Differential Revision: https://phabricator.haskell.org/D5471 }}} See #16013. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 19:37:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 19:37:04 -0000 Subject: [GHC] #16152: Core lint error from PartialTypeSignatures In-Reply-To: <051.267e28704195fd373b6028bcf6ae94c9@haskell.org> References: <051.267e28704195fd373b6028bcf6ae94c9@haskell.org> Message-ID: <066.ab652dae69ddb9ee42c3bbe8212a6ba6@haskell.org> #16152: Core lint error from PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): The `where` clause can be removed completely {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Options_GHC -dcore-lint #-} top :: forall f. _ top = undefined }}} {{{ GHCi, version 8.7.20181230: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 922_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the type ‘forall (f :: k_a1yM) w. w’ @ k_a1yM is out of scope *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) top :: forall (f :: k_a1yM) w. w [LclIdX] top = \ (@ (f_a2Bz :: k_a1yM)) (@ w_a2BA) -> (\ (@ k_a1yM) (@ (f_a1yT :: k_a1yM)) (@ w_a1yL) -> let { $dIP_a2Bq :: ?callStack::CallStack [LclId] $dIP_a2Bq = emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in let { $dIP_a2Bf :: HasCallStack [LclId] $dIP_a2Bf = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "922_bug.hs"#) (I# 8#) (I# 7#) (I# 8#) (I# 16#)) ($dIP_a2Bq `cast` (N:IP[0] <"callStack">_N _N :: (?callStack::CallStack) ~R# CallStack))) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack)) } in letrec { top_a1yU :: w_a1yL [LclId] top_a1yU = break<0>() undefined @ 'LiftedRep @ w_a1yL $dIP_a2Bf; } in top_a1yU) @ Any @ Any @ w_a2BA end Rec } *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 21:04:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 21:04:37 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) Message-ID: <048.c260191f02fda2523355325d46129a68@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We at Homebrew are trying to upgrade the ghc version we ship to 8.6.3. However, many test failures are occurring: https://github.com/Homebrew /homebrew-core/pull/35773 {{{ SUMMARY for test run started at Tue Jan 8 18:16:47 2019 GMT 0:55:14 spent to go through 6521 total tests, which gave rise to 25300 test cases, of which 18851 were skipped 28 had missing libraries 5900 expected passes 90 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 422 unexpected failures 8 unexpected stat failures }}} I am attaching the full build output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 21:06:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 21:06:03 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.1be19c0648b111f49ccf2a7339f9fafe@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fxcoudert): Build output is here: https://gist.github.com/fxcoudert/7d5552ed3d5eb936938a16b3747e4117 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 21:10:09 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 21:10:09 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.87394aa7a1c0df24722f16caab77ec3c@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Phab:D5137 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure what problem we are trying to solve here. The bug, as reported in the Description, is fixed. Yes, ''any'' INLINE pragma results in duplication, of code and/or data. Perhaps some of that duplication could be recovered by CSE; but the first thing is to remove INLINE pragmas that do nothing useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 22:02:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 22:02:10 -0000 Subject: [GHC] #16151: GHC 8.6 build failure on ARM In-Reply-To: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> References: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> Message-ID: <060.6219dbcc189f68cb54077f0a90f2c9bc@haskell.org> #16151: GHC 8.6 build failure on ARM ----------------------------------------+------------------------------ Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): What does `inplace/bin/ghc-stage1 --info` say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 22:13:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 22:13:56 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.abf68f1632e4e3f76a4216c1d8672a6e@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): How do you propose to do step 1 (check that `p` is a subtype of `t2`)? Suppose `p` is `forall a. _ -> a`, and `t2` is `Int -> Int`. Now when we instantiate `p` (to do the subtype check), what do we do about that `_`?? We could satisfy the subtype with `_` = `Int`, or `_` = `a`. The point is that we can't hope to instantiate a partial type signature, and we should not attempt to do so. That's why I suggest that we might just squeeze by if there is visibly no quantification to be done. So I don't think comment:5 will work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 8 22:58:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Jan 2019 22:58:48 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.71138bbf22654df720f66f31b8b82bba@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): It seems like binaries are properly compiled, but running them fails due to not found libraries. {{{ root at talos:$/usr/ports/lang/ghc$ /usr/ports/default/lang/ghc/work/ghc-8.6.3-boot/lib/ghc-8.6.3/bin/ghc ld-elf.so.1: Shared object "libHShaskeline-0.7.4.3-ghc8.6.3.so" not found, required by "ghc" }}} The libraries are there, though: {{{ root at talos:$/usr/ports/lang/ghc$ find work/ghc-8.6.3-boot/libraries -name "*.so" work/ghc-8.6.3-boot/libraries/Cabal/Cabal/dist- install/build/libHSCabal-2.4.0.1-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/array/dist- install/build/libHSarray-0.5.3.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/binary/dist- install/build/libHSbinary-0.8.6.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/bytestring/dist- install/build/libHSbytestring-0.10.8.2-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/containers/dist- install/build/libHScontainers-0.6.0.1-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/deepseq/dist- install/build/libHSdeepseq-1.4.4.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/directory/dist- install/build/libHSdirectory-1.3.3.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/filepath/dist- install/build/libHSfilepath-1.4.2.1-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghc-boot-th/dist-install/build/libHSghc- boot-th-8.6.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghc-boot/dist-install/build/libHSghc- boot-8.6.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghc-compact/dist-install/build/libHSghc- compact-0.1.0.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghc-heap/dist-install/build/libHSghc- heap-8.6.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/ghci/dist- install/build/libHSghci-8.6.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/haskeline/dist- install/build/libHShaskeline-0.7.4.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/hpc/dist- install/build/libHShpc-0.6.0.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/integer-simple/dist-install/build /libHSinteger-simple-0.1.1.1-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/libiserv/dist- install/build/libHSlibiserv-8.6.3-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/mtl/dist- install/build/libHSmtl-2.2.2-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/parsec/dist- install/build/libHSparsec-3.1.13.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/pretty/dist- install/build/libHSpretty-1.1.3.6-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/process/dist- install/build/libHSprocess-1.6.3.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/stm/dist- install/build/libHSstm-2.5.0.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/template-haskell/dist-install/build /libHStemplate-haskell-2.14.0.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/terminfo/dist- install/build/libHSterminfo-0.4.1.2-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/text/dist- install/build/libHStext-1.2.3.1-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/time/dist- install/build/libHStime-1.8.0.2-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/transformers/dist- install/build/libHStransformers-0.5.5.0-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/unix/dist- install/build/libHSunix-2.7.2.2-ghc8.6.3.so work/ghc-8.6.3-boot/libraries/xhtml/dist- install/build/libHSxhtml-3000.2.2.1-ghc8.6.3.so }}} Is it possible to compile binaries statically? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 00:30:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 00:30:44 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.fe9d49ac658cf0dfee1abc1365ad071b@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually this check -- that variables on the RHS are bound on the LHS -- is performed by `TcValidity.checkFamPatBinders`. So I think it can simply be deleted here. It's hard to do correctly because of the implicit kind binders etc. Can you try simply deleting it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 00:36:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 00:36:01 -0000 Subject: [GHC] #16115: Missing associated type instance not reported with error In-Reply-To: <045.a02b44ddfabe4100eda07a68d256646c@haskell.org> References: <045.a02b44ddfabe4100eda07a68d256646c@haskell.org> Message-ID: <060.98995bb78cad69ee25b59ffb0cbd15c0@haskell.org> #16115: Missing associated type instance not reported with error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's true. But it's generally reasonable for errors to suppress warnings. And the error isn't too bad. The user thinks "Why doesn't `Item Nat` equal `()`? Oh, I'd better look in `instance FromList Nat`, since `Item` is an associate type of `FromList`; and sure enough there is no `type instance`. So it's not too bad. If we wanted to change, I can imagine various things we could do: * Never suppress warnings, even if there are errors. * Make it compulsory to give an instance for an associated type, if there is no default in the class. That'd be a language change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 01:25:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 01:25:50 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.b8c226c5633fb9813f3f9599916eee00@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That's a good point. I think that check is a relic from commit 171101beca39befde191baff5027c417bcc709ee, which made an attempt to reject programs like this one: {{{#!hs instance C ('KProxy :: KProxy o) where type F 'KProxy = NatTr (Proxy :: o -> *) }}} Since `o` isn't //explicitly// bound on the left-hand side. However, we later reversed this policy in commit 0829821a6b886788a3ba6989e57e25a037bb6d05, where it was decided that it was OK to mention type variables on the RHSes of type family instances even if they're implicitly bound (i.e., we should accept `F 'KProxy` above). In light of this, I'd agree that `null bad_tvs` validity check serves no purpose. Removing it does make the program work again, (and validates, aside from some expected error message wibbles in `T5515`) which is an encouraging sign. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 01:45:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 01:45:17 -0000 Subject: [GHC] #16115: Missing associated type instance not reported with error In-Reply-To: <045.a02b44ddfabe4100eda07a68d256646c@haskell.org> References: <045.a02b44ddfabe4100eda07a68d256646c@haskell.org> Message-ID: <060.77f1bb19622952636df9ab743934dbb0@haskell.org> #16115: Missing associated type instance not reported with error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think there's a much more conservative option that would be much better. When we come down to wanting `Item Nat ~ ()`, the type checker ''knows'' that `Item Nat` is a stuck type, and it ''knows'' that `()` is not the same stuck type. So the problem can immediately be narrowed down to {{{ Could not match expected type `Item Nat' with actual type `()'. The type family application `Item Nat' is stuck. [etc.] }}} We presumably ''also'' know that `Item` is an associated type of `FromList`, so we should be able to do a bit better, incorporating the information from the suppressed warning: {{{ Could not match expected type `Item Nat' with actual type `()'. No explicit associated type or default declaration for ‘Item’ in the instance declaration for ‘FromList Nat’ [etc.] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 01:46:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 01:46:05 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.756fc77e7b42193aff677004b5ab2fff@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Slightly tangential question: why do type family defaults need type variable binders in the first place? After all, the arguments in a type family default must always be type variables anyway—if you try otherwise: {{{#!hs class C a where type T a type T Int = Int }}} Then GHC will just reject it: {{{ Unexpected type ‘Int’ In the default declaration for ‘T’ A default declaration should have form default T a = ... }}} (That error message is a bit skeevy, since you're not supposed to put the word "`default`" at the front like that. But that's a separate issue.) Given that type family default arguments are required to be all type variables anyway, does it really benefit us to have an explicit `forall` to bind them? (We don't do this for data, class, or type family declarations, for instance.) Or am I missing something obvious? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 01:54:49 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 01:54:49 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive Message-ID: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC produces a warning for the attached source, although it won't compile if the suggested constraints are removed: {{{ redundant-constraint.hs:24:1: warning: [-Wredundant-constraints] • Redundant constraints: (KnownNat 42, Capture 42 p) • In the type signature for: foo :: Foo 42 | 24 | foo :: Foo 42 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 01:55:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 01:55:07 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.dfa2931bb967a728c1f25a8048dfe795@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by fumieval): * Attachment "redundant-constraint.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 02:57:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 02:57:13 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.75fe77bb9d34868d90f9beb76c520cf2@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * differential: Phab:D5409 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 05:12:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 05:12:50 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.2f24657ec1ee596761916536da58677d@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahhh, I think we have actually seen this in manifest in practice in fact (in CI). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 05:25:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 05:25:58 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.b61fed64023a5ef2f755b9f530ede7f1@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe this should be fixed by https://gitlab.haskell.org/ghc/ghc/merge_requests/95. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 06:35:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 06:35:30 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.90e41fce81ac8838405a97843c17eeaf@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I believe #16147 is similar @bgamari, In that case there are multiple OS threads even on the non-threaded runtime. But the `ACQUIRE_LOCK` and `RELEASE_LOCK` macros expand to nothing on the non-threaded runtime, which introduces a race condition with shutdown of the loop and rts. Which is why I think it happens on the non-threaded but not the threaded. See https://ghc.haskell.org/trac/ghc/attachment/ticket/16147/sample.txt I think in this case we always want a lock, so `ACQUIRE_LOCK` and `RELEASE_LOCK` should be changed to `OS_ACQUIRE_LOCK` to `OS_RELEASE_LOCK`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 08:05:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 08:05:02 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.129fb278ca95ba7aa61ca76b30a50f5d@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We should reject egregious examples like {{{ instance C [a] where type F Int = b }}} I hope we do -- and I hope we have a test that checks whether we do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 08:31:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 08:31:19 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.e089515a85fa0733c4da909d7759b3e5@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by simonmar): The code is getting the ccs for the AP_STACK closure from the update frame. I imagine the "ToDo" was to think about whether this is really the right thing. It shouldn't cause a crash - the CCS in the update frame should be valid - and I don't know where else we would get a useful CCS from for the AP_STACK, so it looks reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 08:37:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 08:37:16 -0000 Subject: [GHC] #16143: Some cost centre stacks are not registered via registerCcsList() In-Reply-To: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> References: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> Message-ID: <058.050c7c86506d9dce702819e690f35a78@haskell.org> #16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): CCS_LIST is not used when reporting. It's only used during initialization to chain all the static CCSs together so that they can be assigned unique IDs. See `initProfiling` and `initProfiling2`. So I think you're not finding `base_GHCziIOziHandleziFD_CAFs_cc_ccs` because it was only on the CCS_LIST temporarily during initialization, and you're not finding the dynamic CCSs becuase they never get put on the CCS_LIST. Summary: I think you're barking up the wrong tree here :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 09:26:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 09:26:10 -0000 Subject: [GHC] #16143: Some cost centre stacks are not registered via registerCcsList() In-Reply-To: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> References: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> Message-ID: <058.5ab57192256d993c391fe3c0263dd90a@haskell.org> #16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thanks Simon. Would it make sense to register _all_ CCSs, to be able to use `CCS_LIST` when debugging profiling issues? More specifically I want to use `CCS_LIST` to implement the sanity check I showed in the description, we should help me debug #15508. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 09:27:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 09:27:58 -0000 Subject: [GHC] #16143: Some cost centre stacks are not registered via registerCcsList() In-Reply-To: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> References: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> Message-ID: <058.a3d717f8598eb33edc63782eeeee1307@haskell.org> #16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, I see the problem with this now. That wouldn't work, unless I implement another, module-local list for `initProfiling2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 11:10:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 11:10:11 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.197eb478a72ca9fdc4ab0dcc714c4c53@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Am I correct in believing that this change was part of implementing the [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0007 -instance-foralls.rst explicit foralls GHC proposal]? (Incidentally, this proposal is not listed as "implemented" in [https://github.com/ghc-proposals/ghc- proposals/pulls?page=2&q=label%3AAcceptedthe main list]. Should it be?) The proposal is silent on whether it applies to default family instance decls. It'd be good to update the proposal to be clear on this point, since it is teh only specification we have. If the goal is to be able to explicitly bind every variable, would we need a forall for a default family instance? {{{ class C a where type T a b :: * type T a b = (a, [b]) }} Does the default instance need to replicate the type family signature? Eg can I say this? {{{ class C a where type T a b :: * type T x y = (x, [y]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 14:14:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 14:14:35 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.0546ef456c409c18d27bdf8ae0d529a6@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You can say the last example in comment:3, but you both raise a good question. Do we need these at all? While the variables in the default equation can alpha-vary from other places (I forget why we decided to allow that), they must be bare variables, of the right kinds. So we really know their kinds from the type family declaration. There is no need to be able to write their kinds in the default equation. So perhaps the best way forward is just to remove the featurette. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 14:14:45 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 14:14:45 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.9fc684082792d0db90c357a09f0e4e91@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Regardless, yes, we should update the proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 14:41:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 14:41:12 -0000 Subject: [GHC] #16155: Pattern Synonym for Ratio Message-ID: <045.ce08db94d22390d42df2c4c4a01fd23d@haskell.org> #16155: Pattern Synonym for Ratio -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms, Ratio | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Data.Ratio` should export a simple pattern synonym that can be used by `Safe` code. {{{#!hs infixl 7 :%: pattern n :%: d <- n :% d where n :%: d = n % d }}} It'd be much simpler to use than `numerator` and `denominator`, and pattern matching on it would turn into a regular pattern match, hopefully for free. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 14:43:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 14:43:30 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.948126f30e0d53770fbff586e013af53@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:17 pkubaj]: > Is it possible to compile binaries statically? Yes, set `DYNAMIC_GHC_PROGRAMS = NO` in your `build.mk`. See [[wiki:DynamicGhcPrograms]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:00:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:00:40 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.f1cb9233ef2652fe5cf52da71a87e88e@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:24:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:24:05 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.00a70e1cad47e8498df5cb96d8ca1f6c@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Quite right in comment:6. We can't possibly instantiate a partial type. So then I got to thinking that we would check the ascribed expression first, followed by the subtype check (presumably after the partial type is no longer partial). But we should ''already'' be doing that. So I dived deeper, and I found more interesting things. We have, as before {{{#!hs data G a where G1 :: G Char G2 :: G Bool }}} I wish for this to be accepted: {{{#!hs foo :: forall a. G a -> a foo x = ((case x of G1 -> 'z' G2 -> True) :: _) }}} Why is it rejected today? It's not just that the wildcard is untouchable in the context of the GADT pattern-match. Here's what happens: we invent a new metavariable `_w` to stand for the wildcard. This `_w` is untouchable in the GADT pattern match, so we don't learn anything about it. Then, critically, we try to ''generalize'' the signature. This takes the unsolved metavariable `_w` and ''skolemizes'' it. So, later, when the subtype-checker tries to unify `_w` with the type variable `a`, it fails, as `_w` is a skolem. This behavior isn't entirely unreasonable. But note that I never asked for generalization. Contrast with the fact that (if I say `default ()`), GHC rejects {{{#!hs wurble :: _ wurble x = x + 1 }}} This is rejected because my partial type signature did not allow for any constraints (I need `Num a => a -> a`): GHC does not allow `_` to stand for `_ => _`. Yet GHC ''does'' allow `_` to stand for `forall a. a -> a`: changing `wurble` to be `wurble x = x` works just fine. This seems like inconsistent design, to me. So, I wonder if we should allow generalization in wildcards only by user request, with something like `forall _. _`, just like we do so currently for constraints. We could also have `forall a b c _ . ...`, just like we now can have an extra-constraints wildcard. (The `_` in `forall a b c _` isn't really a wildcard, but a request for generalization.) I'm not sure how implementable this is, but it's a decent thought experiment. Of course, the idea that "wildcards should not be generalized" reminded me of something else that should not be generalized: lets. And indeed we see some strange behavior around `let` and GADT inference. This isn't related to partial type signatures, but it's a bit more grist for the mill. Consider this: {{{#!hs bar :: G a -> a bar z = quux z where quux x = case x of G1 -> 'b' G2 -> True }}} This is rejected. `quux` is checked just like it were at top level, and we can't figure out its type. This is true even though bidirectional type- checking tells us that the type of `quux` should be `G a -> a`. However, earlier I argued that the problem is ''generalization''. So, let's suppress that urge of GHC's: {{{#!hs bar2 :: G a -> a bar2 z = quux2 z where quux2 x = case x of G1 -> const 'b' z G2 -> True }}} This is accepted! In the case-match for `G1`, I have an entirely- irrelevant use of the outer variable `z`. According to the rules for let- should-not-be-generalized, the appearance of a variable from an outer scope disables generalization. And so `quux2` is not generalized, meaning that its type still contains proper metavariables when we check that `quux2 z` has type `a`, and then GHC can infer the correct type. Relating back to partial type signatures, now we try {{{#!hs bar3 :: G a -> a bar3 z = quux3 z where quux3 :: _ quux3 x = case x of G1 -> const 'b' z G2 -> True }}} The only change here is the partial type signature. Because GHC does not respect let-should-not-be-generalized in the presence of partial type signatures, this is rejected again. Bottom line: it's nice to have finer control over generalization. The work on let-should-not-be-generalized supposed that a good heuristic for when to stop generalization was the presence of a variable from an outer scope. This has indeed served us well, and I don't propose changing it. But it might be nice to give users a way to control this behavior more directly. Having a partial type signature `xyz :: _` might be a signal saying not to generalize something that ordinarily would (helpful in my `quux` example) and having a partial type signature `xyz :: forall _. _` might a signal saying to generalize something that ordinarily wouldn't. This is useful: See Section 10.2 of my (as-yet-unpublished) [https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.pdf Stitch paper]. (That section mentions 2 places where generalization is good. Interestingly, GHC has already adapted to the first point. The second point is of interest here, where I brutally just specified `-XNoMonoLocalBinds` in order to get generalization.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:31:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:31:20 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.c68236889f043ce50f9b69f3d14cafd9@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So we really know their kinds from the type family declaration. There is no need to be able to write their kinds in the default equation. So perhaps the best way forward is just to remove the featurette. I agree. And let's update the proposal to match. We should also document whatever we decide (including the alpha-varying bit) in the user manual -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:39:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:39:01 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.4940687d5c8fe5c1ea75e5c3effba2f1@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wonder: will we need to change some Template Haskell conventions to support this change? Currently, this: {{{#!hs [d| class C a where type T a type T a = a |] }}} Turns into this: {{{#!hs [ ClassD [] C_6989586621679039759 [ PlainTV a_6989586621679039761 ] [] [ OpenTypeFamilyD (TypeFamilyHead T_6989586621679039760 [ PlainTV a_6989586621679039761 ] NoSig Nothing) , TySynInstD (TySynEqn Nothing (AppT (ConT T_6989586621679039760) (VarT a_6989586621679039762)) (VarT a_6989586621679039762)) ] ] }}} Notice that we're using a `TySynInstD`/`TySynEqn` to represent the type family default, complete with a `Nothing` for its type variable binders. If we pursue the line of thought in this ticket, wouldn't that suggest that we should be using something else to represent this default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:48:36 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:48:36 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.7e3f2959a1fb908b7b93a1bef1adef22@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D5473 => Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/97 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:53:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:53:41 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.26195de313229288b9bb9eeb6c989249@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Another interesting example has cropped up. Re-consider {{{#!hs wurble :: _ wurble x = x }}} This is accepted, because the type `_` allows for implicit generalization. But what about {{{#!hs wurble2 :: forall. _ wurble2 x = x }}} To my surprise, this is accepted too, with `wurble2 :: forall a. a -> a`. Yet, I would have expected my `forall.` to say that there are no quantified variables in the type of `wurble2`. So, maybe another design is this: `foo :: _` can be generalized. (This is at odds with the fact that `foo` cannot have constraints.) But if there is an explicit `forall` in type of `foo`, we appeal to the forall-or-nothing rule and say that the variables quantified in the `forall` are precisely the quantified variables; no more can be inferred. Then, we can suppress quantification in `forall. _`. One advantage here is that this new design is backward compatible (though I'm not terribly worried about that here). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:54:15 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:54:15 -0000 Subject: [GHC] #16156: Broken tests on Windows Message-ID: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> #16156: Broken tests on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'll be marking these as broken: {{{ Unexpected results from: TEST="T10598_TH T11072gcc T12530 T13618 T15324 T15858 T15904 T2276_ghci T7477 T8759 T9086 TH_NestedSplices dynbrk004 plugin-recomp-change plugin- recomp-flags plugin-recomp-impure plugins09 plugins10 plugins11 print009 print012 print023 result001" SUMMARY for test run started at Mon Jan 7 01:57:14 2019 GST 1:57:17 spent to go through 6747 total tests, which gave rise to 19416 test cases, of which 12221 were skipped 47 had missing libraries 6945 expected passes 180 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 23 unexpected failures 0 unexpected stat failures Unexpected failures: ffi/should_run/T2276_ghci.run T2276_ghci [bad exit code] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) ghc-e/should_run/T9086.run T9086 [bad exit code] (normal) ghci.debugger/scripts/print009.run print009 [bad exit code] (ghci- ext) ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci- ext) ghci.debugger/scripts/print023.run print023 [bad exit code] (ghci- ext) hp2ps/T15904.run T15904 [bad exit code] (normal) ghci.debugger/scripts/dynbrk004.run dynbrk004 [bad exit code] (ghci- ext) ghci.debugger/scripts/result001.run result001 [bad exit code] (ghci- ext) plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) plugins/T15858.run T15858 [bad exit code] (ghci) th/TH_NestedSplices.run TH_NestedSplices [exit code non-0] (normal) th/T7477.run T7477 [exit code non-0] (ext- interp) th/T8759.run T8759 [exit code non-0] (ext- interp) th/T10598_TH.run T10598_TH [exit code non-0] (normal) th/T12530.run T12530 [exit code non-0] (normal) th/T13618.run T13618 [exit code non-0] (normal) th/T15324.run T15324 [exit code non-0] (ext- interp) plugins/plugins09.run plugins09 [bad stdout] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:54:57 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:54:57 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.e408c4a3aa91ff836b8439c2f3ed3aad@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 15:58:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 15:58:37 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.5a3461c6e3d32eabafc8484cba679521@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Also amongst all this was the observation that let-should-not-be- generalized is ignore in the presence of partial type signatures. Is this a good thing? I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:00:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:00:33 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.1fcea1d951bb11715e7627ebccaafdd7@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Not necessarily. We could always just check during conversion that there are no binders for type family defaults. I don't think it's a big deal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:06:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:06:18 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it In-Reply-To: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> References: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> Message-ID: <062.e5d44b680695e1a0af1b6be76f9a2b45@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: interpreter Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse, bgamari (added) Comment: I'm interested in trying to work on this one if it is still something we want. Is there anything I should think about? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:08:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:08:23 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.ebee1c96950a378c0ae8a5711b0dd7df@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That example is rejected with a `Not in scope: type variable ‘b’` error, before and after the patch, since `b` is simply not bound anywhere. A more interesting example is the one from `T5515`: {{{#!hs instance ctx a => Bome ctx where type BArg ctx = a }}} This time, `a` technically //is// in scope over the type family equation. However, it's not bound on the LHS of the equation, so it's rejected. After this patch, the new error message becomes: {{{#!diff diff -uw "indexed-types/should_fail/T5515.run/T5515.stderr.normalised" "indexed-types/should_fail/T5515.run/T5515.comp.stderr.normalised" --- indexed-types/should_fail/T5515.run/T5515.stderr.normalised 2019-01-09 11:08:03.005471816 -0500 +++ indexed-types/should_fail/T5515.run/T5515.comp.stderr.normalised 2019-01-09 11:08:03.005471816 -0500 @@ -1,8 +1,24 @@ -T5515.hs:9:3: - The RHS of an associated type declaration mentions out-of-scope variable ‘a’ - All such variables must be bound on the LHS +T5515.hs:6:16: + Expecting one more argument to ‘ctx’ + Expected a type, but ‘ctx’ has kind ‘* -> Constraint’ + In the first argument of ‘Arg’, namely ‘ctx’ + In the first argument of ‘ctx’, namely ‘(Arg ctx)’ + In the class declaration for ‘Bome’ -T5515.hs:15:3: - The RHS of an associated type declaration mentions out-of-scope variable ‘a’ - All such variables must be bound on the LHS +T5515.hs:14:1: + Type variable ‘a’ is mentioned in the RHS, + but not bound on the LHS of the family instance + In the type instance declaration for ‘Arg’ + In the instance declaration for ‘Some f’ + +T5515.hs:14:10: + Could not deduce (C f a0) + from the context: C f a + bound by an instance declaration: + forall f a. C f a => Some f + at T5515.hs:14:10-24 + The type variable ‘a0’ is ambiguous + In the ambiguity check for an instance declaration + To defer the ambiguity check to use sites, enable AllowAmbiguousTypes + In the instance declaration for ‘Some f’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:15:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:15:52 -0000 Subject: [GHC] #16157: Duplicate symbol error on Windows Message-ID: <046.e07bce9c47134d11290b77c481236607@haskell.org> #16157: Duplicate symbol error on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `T11072gcc` is failing on Windows with {{{ Wrong exit code for T11072gcc()(expected 0 , actual 2 ) Stderr ( T11072gcc ): GHC runtime linker: fatal error: I found a duplicate definition for symbol ghczmprim_GHCziClasses_zdp31ZLzvz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUzvZR_info whilst processing object file C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\testsuite\tests\ghci\linking\dyn\T11072gcc.run\bin_impl_gcc\libASx.dll.a The symbol was previously defined in C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\libraries\ghc-prim\dist- install\build\HSghc-prim-0.5.3.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.7.20190106 for x86_64-unknown-mingw32): loadArchive "C:\\GitLabRunner\\builds\\78d7d3f9\\0\\ghc\\ghc\\testsuite\\tests\\ghci\\linking\\dyn\\T11072gcc.run\\bin_impl_gcc\\libASx.dll.a": failed Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[2]: *** [Makefile:85: compile_libAS_impl_gcc] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:21:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:21:51 -0000 Subject: [GHC] #16158: T15094 fails on Windows Message-ID: <046.2895b324e85c19f2124161b1224966d8@haskell.org> #16158: T15094 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `T15904` fails with: {{{ =====> T15904(normal) 1996 of 6747 [0, 6, 0] cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904 Wrong exit code for T15904()(expected 0 , actual 2 ) Stdout ( T15904 ): [1 of 1] Compiling T15904 ( T15904.hs, T15904.o ) Linking "T15904".exe ... Stderr ( T15904 ): "T15904".exe.manifest: openFile: invalid argument (Invalid argument) make[2]: *** [Makefile:7: T15904] Error 1 *** unexpected failure for T15904(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:23:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:23:31 -0000 Subject: [GHC] #16159: plugin-recomp-change fails on Windows Message-ID: <046.214affca4fe4fe7694b42a671b8a7a3c@haskell.org> #16159: plugin-recomp-change fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Wrong exit code for plugin-recomp-change()(expected 0 , actual 2 ) Stderr ( plugin-recomp-change ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run C://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-7bwXt6gOi6GLkV25gq6uB8 collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) make[2]: *** [Makefile:112: plugin-recomp-change] Error 1 *** unexpected failure for plugin-recomp-change(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:28:46 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:28:46 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows Message-ID: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> #16160: TH_NestedSplices fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ Compile failed (exit code 11) errors were: Access violation in generated code when executing data at 0x0 Attempting to reconstruct a stack trace... Frame Code address Null address *** unexpected failure for TH_NestedSplices(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:31:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:31:52 -0000 Subject: [GHC] #16161: plugin-recomp-impure fails on Windows Message-ID: <046.3a3fd3bac1424959fa2b8edea489f7f1@haskell.org> #16161: plugin-recomp-impure fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) Stdout ( plugin-recomp-impure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin- recomp-test.o ) Stderr ( plugin-recomp-impure ): Access violation in generated code when executing data at 0x0 Attempting to reconstruct a stack trace... Frame Code address Null address make[2]: *** [Makefile:98: plugin-recomp-impure] Error 11 *** unexpected failure for plugin-recomp-impure(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:32:48 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:32:48 -0000 Subject: [GHC] #16159: plugin-recomp-change fails on Windows In-Reply-To: <046.214affca4fe4fe7694b42a671b8a7a3c@haskell.org> References: <046.214affca4fe4fe7694b42a671b8a7a3c@haskell.org> Message-ID: <061.eccaca5b0bcc6ad99fbe42f4136832c0@haskell.org> #16159: plugin-recomp-change fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): #16161 is another different failure in `plugin-recomp-impure`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:33:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:33:10 -0000 Subject: [GHC] #16159: plugin-recomp-change fails on Windows In-Reply-To: <046.214affca4fe4fe7694b42a671b8a7a3c@haskell.org> References: <046.214affca4fe4fe7694b42a671b8a7a3c@haskell.org> Message-ID: <061.187084ee8a384288328acb40acf307e1@haskell.org> #16159: plugin-recomp-change fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `plugin-recomp-flags` fails for similar reasons: {{{ cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/GitLabRunner/builds/78d7d3f9/0/ghc/ghc/testsuite cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory plugin-recomp-flags Wrong exit code for plugin-recomp-flags()(expected 0 , actual 2 ) Stdout ( plugin-recomp-flags ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin- recomp-test.o ) Linking plugin-recomp-test.exe ... Stderr ( plugin-recomp-flags ): Simple Plugin Passes Queried Got options: 0 Simple Plugin Pass Run C://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-7bwXt6gOi6GLkV25gq6uB8 collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) make[2]: *** [Makefile:104: plugin-recomp-flags] Error 1 *** unexpected failure for plugin-recomp-flags(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:35:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:35:20 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.f95f381a3cf97392d68e7cf57ce391ac@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Actually, it looks like most of these merely timed out. Specifically: ||= Test =||= Reason =|| || `foreignInterruptible(ghci)` || saw exit code 1, expected 0 || || `T2276_ghci` || timed out || || `T11072gcc` || see #16157 || || `T9086(normal)` || timed out || || `print009(ghci-ext)` || timed out || || `print012(ghci-ext)` || timed out || || `print023(ghci-ext)` || timed out || || `T15904(normal)` || #16158 || || `dynbrk004(ghci-ext)` || timed out || || `result001(ghci-ext)` || timed out || || `plugin-recomp-change(normal)` || #16159 || || `T15858(ghci)` || timed out || || `heapprof001(ghci-ext-prof)` || saw exit code 1, expected 0 || || `scc001(ghci-ext-prof)` || saw exit code 1, expected 0 || || `scc002(ghci-ext-prof)` || saw exit code 1, expected 0 || || `scc003(ghci-ext-prof)` || saw exit code 1, expected 0 || || `scc005(ghci-ext-prof)` || saw exit code 1, expected 0 || || `T680(ghci-ext-prof)` || saw exit code 1, expected 0 || || `T2552(ghci-ext-prof)` || saw exit code 1, expected 0 || || `prof-doc-fib(ghci-ext-prof)` || saw exit code 1, expected 0 || || `prof-doc-last(ghci-ext-prof)` || saw exit code 1, expected 0 || || `T5559(ghci-ext-prof)` || saw exit code 1, expected 0 || || `T5363(ghci-ext-prof)` || saw exit code 1, expected 0 || || `profinline001(ghci-ext-prof)` || saw exit code 1, expected 0 || || `T12962(ghci-ext-prof)` || saw exit code 1, expected 0 || || `TH_NestedSplices(normal)` || #16160 || || `T7477(ext-interp)` || timed out || || `T8759(ext-interp)` || timed out || || `T10598_TH(normal)` || timed out || || `T12530(normal)` || timed out || || `T13618(normal)` || timed out || || `T15324(ext-interp)` || timed out || || `plugin-recomp-impure(normal)` || #16161 || || `plugin-recomp-flags(normal)` || #16159 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:36:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:36:47 -0000 Subject: [GHC] #16118: SYB link in Data.Data is dead In-Reply-To: <045.8bbd8a67c43b7423e7fe4ecadaf4cfc6@haskell.org> References: <045.8bbd8a67c43b7423e7fe4ecadaf4cfc6@haskell.org> Message-ID: <060.32e2e8ae42bf1c647dd9f17ca1078e68@haskell.org> #16118: SYB link in Data.Data is dead -------------------------------------+------------------------------------- Reporter: ocramz | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Zemyla): Here's an archive.org link for it: http://web.archive.org/web/20170518091839/http://foswiki.cs.uu.nl/foswiki/GenericProgramming/SYB -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:40:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:40:56 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.1c7b8d5ef6265d02e3bf46c38303fc59@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Zemyla): Can you provide us with dumps, like with `-ddump-simpl` and such? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:45:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:45:18 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.72ab312c3736474de163a2f04effbdc1@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O0-nollvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:45:27 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:45:27 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.6ecabffb03ac48938359455dafb16119@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O1-nollvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:45:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:45:39 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.d8b60d84c53626fc19ec57cbe4e6bd39@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O2-nollvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:45:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:45:52 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.c1bbe3471efb51cdff230185b2dc5c4c@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O0-llvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:46:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:46:02 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.94ac11da9c720df74befd3964ec53c67@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O1-llvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:46:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:46:10 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.7c2409829507cb45a5c42e550aaa13ce@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.dump-simpl-O2-llvm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:47:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:47:19 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.8916860d9b32db30b5ebd7ad36b8906d@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've attached the `-ddump-simpl` output for each combination. (For instance, `Bug.dump-simpl-O0-nollvm` is for the `-O0` variant, and `Bug .dump-simpl-O0-llvm` is for the `-O0 -llvm` variant.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:51:49 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:51:49 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.34e18a3e9eecc399bb0abfac1b5edb64@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:17 pkubaj]: > {{{ > root at talos:$/usr/ports/lang/ghc$ /usr/ports/default/lang/ghc/work/ghc-8.6.3-boot/lib/ghc-8.6.3/bin/ghc > ld-elf.so.1: Shared object "libHShaskeline-0.7.4.3-ghc8.6.3.so" not found, required by "ghc" > > }}} Do not use `ghc` in `/lib` but the shell script `ghc` in `/bin`. It sets an `LD-LIBRARY_PATH` if necessary. > > The libraries are there, though: > > {{{ > root at talos:$/usr/ports/lang/ghc$ find work/ghc-8.6.3-boot/libraries -name "*.so" > work/ghc-8.6.3-boot/libraries/Cabal/Cabal/dist- install/build/libHSCabal-2.4.0.1-ghc8.6.3.so > [...] > }}} This looks like you did not do `make install`. In that case you want to use `inplace/bin/ghc-stage2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:56:27 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:56:27 -0000 Subject: [GHC] #16162: External interpreter is broken on Windows Message-ID: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> #16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is plenty of evidence to suggest that the external interpreter is currently broken on Windows: * #14271 reports crashes when running `ghci` * #16156 reports a number of testsuite failures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:56:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:56:44 -0000 Subject: [GHC] #16162: External interpreter is broken on Windows In-Reply-To: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> References: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> Message-ID: <061.a3e3659a616503974305accdb16df9cb@haskell.org> #16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:56:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:56:54 -0000 Subject: [GHC] #16162: External interpreter is broken on Windows In-Reply-To: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> References: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> Message-ID: <061.7a9a0aa3fd8f31995383cdabfa3b0319@haskell.org> #16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:57:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:57:13 -0000 Subject: [GHC] #14271: External interpreter is broken (was: ghci hangs with -fexternal-interpreter -prof) In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.2115f932ff19af5af27917244e39d454@haskell.org> #14271: External interpreter is broken -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: RemoteGHCi Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #16162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #16162 Comment: I'm going to close this in favor of #16162. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:57:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:57:32 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.21f998d5f49a0e291d82565d2147a472@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): I've opened #16162 to track the many external-interpreter issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:59:24 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:59:24 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows In-Reply-To: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> References: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> Message-ID: <059.d878cafe4084b37c8df8d49910998e1b@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Resolution: | Keywords: RemoteGHCi Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 16:59:53 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 16:59:53 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows In-Reply-To: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> References: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> Message-ID: <059.e27d2b86db9afdf359d366f2f82e4cce@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Resolution: | Keywords: RemoteGHCi Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:00:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:00:42 -0000 Subject: [GHC] #16158: T15094 fails on Windows In-Reply-To: <046.2895b324e85c19f2124161b1224966d8@haskell.org> References: <046.2895b324e85c19f2124161b1224966d8@haskell.org> Message-ID: <061.e3731d01aa93b31946888c2a06f39378@haskell.org> #16158: T15094 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:01:36 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:01:36 -0000 Subject: [GHC] #16162: External interpreter is broken on Windows In-Reply-To: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> References: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> Message-ID: <061.13789f5e4e2bc97f128fd14b8ba58662@haskell.org> #16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): However, it apparently isn't *completely* broken since #14576 recommends using it to workaround another bug on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:03:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:03:31 -0000 Subject: [GHC] #16162: External interpreter is broken on Windows In-Reply-To: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> References: <046.94441033a4a74a7f96a56cbf72d42bb5@haskell.org> Message-ID: <061.d8005f3772b1faccd6db5495aabe5209@haskell.org> #16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > There is plenty of evidence to suggest that the external interpreter is > currently broken on Windows: > > * #14271 reports crashes when running `ghci` > * #16156 reports a number of testsuite failures New description: There is plenty of evidence to suggest that the external interpreter is currently broken on Windows: * #14271 reports crashes when running `ghci` * #16156 reports a number of testsuite failures, particularly in the `ghci-ext-prof` way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:10:24 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:10:24 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.5db0bec5249fe9a259edce3ba1b78f94@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5412, Wiki Page: | Phab:D5422 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * resolution: => fixed Comment: We eliminated all the costly enumerations and the recompilation check is now reasonably fast (I'm sure it can be improved further), so let's close this and open specific tickets if some performance problems show up elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:10:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:10:31 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof (was: External interpreter is broken) In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.63d443712d4297bd36301bbf561d71c8@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: RemoteGHCi Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #16162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:19:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:19:21 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.f2c1ada10ca1c1a90786cceb9ca76ec6@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: RemoteGHCi Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #16162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I have reported a number of external-interpreter-related testsuite failures on Windows in #16156. The most common failure mode is the test timing-out, which I suspect is due to this hang reported in this ticket. My suspicion is that GHC's logic to detect the death of its `iserv` process is broken on Windows. I did the following to test this: 1. start `ghci -fexternal-interpreter` 2. issue a kill request against its associated interpreter process (using the "kill" command in Process Explorer) 3. try evaluating `print "hello"` 4. observe that `ghci` indeed hangs However, I should note that in this experiment the kill request against the interpreter doesn't actually kill the interpreter process. Rather it seems to merely hang. Issuing a *second* kill command indeed kills it, at which point `ghci` realizes the interpreter is dead and terminates. The backtrace of the interpreter process in its hung state looks like the following: {{{ (gdb) thread apply all bt Thread 6 (Thread 9232.0x19ac): #0 0x00007ffa06549351 in ntdll!DbgBreakPoint () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa065710ba in ntdll!DbgUiRemoteBreakin () from /c/Windows/SYSTEM32/ntdll.dll #2 0x00007ffa061c8364 in KERNEL32!BaseThreadInitThunk () from /c/Windows/System32/KERNEL32.DLL #3 0x00007ffa0650e851 in ntdll!RtlUserThreadStart () from /c/Windows/SYSTEM32/ntdll.dll #4 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 5 (Thread 9232.0x1c5c): #0 0x00007ffa06545b84 in ntdll!ZwWaitForSingleObject () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa03413ebf in WaitForSingleObjectEx () from /c/Windows/System32/KERNELBASE.dll #2 0x0000000003d70543 in waitCondition (pCond=pCond at entry=0x6c2c768, pMut=pMut at entry=0x6c2c770) at rts\win32\OSThreads.c:87 #3 0x0000000003d54d60 in waitForWorkerCapability (task=0x6c2c760) at rts\Capability.c:651 #4 yieldCapability (pCap=pCap at entry=0x857fe88, task=task at entry=0x6c2c760, gcAllowed=gcAllowed at entry=true) at rts\Capability.c:888 #5 0x0000000003d57191 in scheduleYield (task=0x6c2c760, pcap=0x857fea0) at rts\Schedule.c:672 #6 schedule (initialCapability=, task=, task at entry=0x6c2c760) at rts\Schedule.c:292 #7 0x0000000003d5826f in scheduleWorker (cap=, task=0x6c2c760) at rts\Schedule.c:2550 #8 0x0000000003d7e4f8 in workerStart (task=0x6c2c760) at rts\Task.c:444 #9 0x00007ffa061c8364 in KERNEL32!BaseThreadInitThunk () from /c/Windows/System32/KERNEL32.DLL #10 0x00007ffa0650e851 in ntdll!RtlUserThreadStart () from /c/Windows/SYSTEM32/ntdll.dll #11 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 4 (Thread 9232.0x20b8): #0 0x00007ffa06545b84 in ntdll!ZwWaitForSingleObject () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa03413ebf in WaitForSingleObjectEx () from /c/Windows/System32/KERNELBASE.dll #2 0x0000000003d70543 in waitCondition (pCond=pCond at entry=0x4d8ee88, pMut=pMut at entry=0x4d8ee90) at rts\win32\OSThreads.c:87 #3 0x0000000003d54d60 in waitForWorkerCapability (task=0x4d8ee80) at rts\Capability.c:651 #4 yieldCapability (pCap=pCap at entry=0x770fe88, task=task at entry=0x4d8ee80, gcAllowed=gcAllowed at entry=true) at rts\Capability.c:888 #5 0x0000000003d57191 in scheduleYield (task=0x4d8ee80, pcap=0x770fea0) at rts\Schedule.c:672 #6 schedule (initialCapability=, task=, task at entry=0x4d8ee80) at rts\Schedule.c:292 #7 0x0000000003d5826f in scheduleWorker (cap=, task=0x4d8ee80) at rts\Schedule.c:2550 #8 0x0000000003d7e4f8 in workerStart (task=0x4d8ee80) at rts\Task.c:444 #9 0x00007ffa061c8364 in KERNEL32!BaseThreadInitThunk () from /c/Windows/System32/KERNEL32.DLL #10 0x00007ffa0650e851 in ntdll!RtlUserThreadStart () from /c/Windows/SYSTEM32/ntdll.dll #11 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 3 (Thread 9232.0x2098): #0 0x00007ffa06545b84 in ntdll!ZwWaitForSingleObject () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa03413ebf in WaitForSingleObjectEx () from /c/Windows/System32/KERNELBASE.dll #2 0x0000000003c5745d in caqi_info () #3 0x0000000004d8e7e0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 9232.0x7ac): #0 0x00007ffa065492d4 in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa064c9e4e in ntdll!RtlReleaseSRWLockExclusive () from /c/Windows/SYSTEM32/ntdll.dll #2 0x00007ffa061c8364 in KERNEL32!BaseThreadInitThunk () from /c/Windows/System32/KERNEL32.DLL #3 0x00007ffa0650e851 in ntdll!RtlUserThreadStart () from /c/Windows/SYSTEM32/ntdll.dll #4 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 1 (Thread 9232.0x18d4): #0 0x00007ffa06545c04 in ntdll!ZwWriteFile () from /c/Windows/SYSTEM32/ntdll.dll #1 0x00007ffa034140e6 in WriteFile () from /c/Windows/System32/KERNELBASE.dll #2 0x00007ffa052e03db in msvcrt!_write () from /c/Windows/System32/msvcrt.dll #3 0x00007ffa052dfcca in msvcrt!_write () from /c/Windows/System32/msvcrt.dll #4 0x0000000003b2cc20 in s9ja_info () #5 0x0000000000000006 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:20:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:20:20 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.f85367df8ce2b9f1a9124ca5280313b8@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Now that #15999 has a fix, I redid some of the benchmarks. Before I got distracted, we were discussing whether the allocation heuristic ("don't allow closure growth") is really effective. Here are the results against 8.6 as the baseline: https://gist.github.com/sgraf812/d3eb0b2251512a1845adcbf356248c25 `ll-$date` is disallowing closure growth (notice absence of any regression in allocations), whereas `ll-c2-$date` allows closure growth and yields marginally better counted instructions at that. I expected more regressions in `ll-c2`, but there's really just `paraffins` regressing by over 1% wrt. `ll`. Note that `wheel-sieve1` still regresses by 28.7% in allocations, while not providing a real benefit. Let's see what `paraffins` is up to and what runtime measurements suggest. Maybe we can get rid of the closure growth heuristic (which would be a shame, but that's science). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:24:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:24:31 -0000 Subject: [GHC] #16157: Duplicate symbol error on Windows In-Reply-To: <046.e07bce9c47134d11290b77c481236607@haskell.org> References: <046.e07bce9c47134d11290b77c481236607@haskell.org> Message-ID: <061.ab41a2aa5d481de436ce0f2ca71ee955@haskell.org> #16157: Duplicate symbol error on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): This is a ghc annoyance that when you use it to compile a shared library it will include haskell symbol even if they're not used, because we compile with export-all enabled. I guess I should finally bite the bullet and just use gcc directly.. The test is broken too often. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:26:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:26:22 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.0bc605503810141d7333022097e73da4@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Did you try rerunning the testsuite again with only these tests single threaded @bgamari? There shouldn't be this many failing, but the testsuite has been exhibiting threading related issues for a while now. Hasn't been very high on my list to look at I must admit... Should probably do.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:31:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:31:43 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.f9b085a01d3e8028d2403ad4cf3f8cf9@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: RemoteGHCi Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #16162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It looks like thread 4 and 5 are blocked waiting for something. Can you print the tasks's blocked reason? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:34:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:34:37 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.c417fcf13f772c6b649424d53f96680d@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"8632268ad8405f0c01aaad3ad16e23c65771ba49/nofib" 8632268/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="8632268ad8405f0c01aaad3ad16e23c65771ba49" Stabilise benchmarks wrt. GC Summary: This is due to #15999, a follow-up on #5793 and #15357 and changes all benchmarks, some of them (i.e. `wheel-sieve1`, `awards`) rather drastically. The general plan is outlined in #15999: Identify GC-sensitive benchmarks by looking at how productivity rates change over different nursery sizes and iterate `main` of these benchmarks often enough for the non-monotony and discontinuities to go away. I was paying attention that the benchmarked logic is actually run $n times more often, rather than just benchmarking IO operations printing the result of CAFs. When I found benchmarks with insignificant runtime (#15357), I made sure that parameters/input files were adjusted so that runtime of the different modes fall within the ranges proposed in https://ghc.haskell.org/trac/ghc/ticket/15357#comment:4 - fast: 0.1-0.2s - norm: 1-2s - slow: 5-10s This is what I did: - Stabilise bernoulli - Stabilise digits-of-e1 - Stabilise digits-of-e2 - Stabilise gen_regexp - Adjust running time of integrate - Adjust running time of kahan - Stabilise paraffins - Stabilise primes - Adjust running time of rfib - Adjust running time of tak - Stabilise wheel-sieve1 - Stabilise wheel-sieve2 - Adjust running time of x2n1 - Adjust running time of ansi - Adjust running time of atom - Make awards benchmark something other than IO - Adjust running time of banner - Stabilise boyer - Adjust running time of boyer2 - Adjust running time of queens - Adjust running time of calendar - Adjust runtime of cichelli - Stabilise circsim - Stabilise clausify - Stabilise constraints with moderate success - Adjust running time of cryptarithm1 - Adjust running time of cryptarythm2 - Adjust running time of cse - Adjust running time of eliza - Adjust running time of exact-reals - Adjust running time of expert - Stabilise fft2 - Stabilise fibheaps - Stabilise fish - Adjust running time for gcd - Stabilise comp_lab_zift - Stabilise event - Stabilise fft - Stabilise genfft - Stabilise ida - Adjust running time for listcompr - Adjust running time for listcopy - Adjust running time of nucleic2 - Attempt to stabilise parstof - Stabilise sched - Stabilise solid - Adjust running time of transform - Adjust running time of typecheck - Stabilise wang - Stabilise wave4main - Adjust running time of integer - Adjust running time of knights - Stabilise lambda - Stabilise lcss - Stabilise life - Stabilise mandel - Stabilise mandel2 - Adjust running time of mate - Stabilise minimax - Adjust running time of multiplier - Adjust running time of para - Stabilise power - Adjust running time of primetest - Stabilise puzzle with mild success - Adjust running time for rewrite - Stabilise simple with mild success - Stabilise sorting - Stabilise sphere - Stabilise treejoin - Stabilise anna - Stabilise bspt - Stabilise cacheprof - Stablise compress - Stablise compress2 - Stabilise fem - Adjust running time of fluid - Stabilise fulsom - Stabilise gamteb - Stabilise gg - Stabilise grep - Adjust running time of hidden - Stabilise hpg - Stabilise infer - Stabilise lift - Stabilise linear - Attempt to stabilise maillist - Stabilise mkhprog - Stabilise parser - Stabilise pic - Stabilise prolog - Attempt to stabilise reptile - Adjust running time of rsa - Adjust running time of scs - Stabilise symalg - Stabilise veritas - Stabilise binary-trees - Adjust running time of fasta - Adjust running time of k-nucleotide - Adjust running time of pidigits - Adjust running time of reverse-complement - Adjust running time of spectral-norm - Adjust running time of fannkuch-redux - Adjust running time for n-body Problematic benchmarks: - `last-piece`: Unclear how to stabilise. Runs for 300ms and I can't make up smaller inputs because I don't understand what it does. - `pretty`: It's just much too small to be relevant at all. Maybe we want to get rid of this one? - `scc`: Same as `pretty`. The input graph for which SCC analysis is done is much too small and I can't find good directed example graphs on the internet. - `secretary`: Apparently this needs `-package random` and consequently hasn't been run for a long time. - `simple`: Same as `last-piece`. Decent runtime (70ms), but it's unstable and I see no way to iterate it ~100 times in fast mode. - `eff`: Every benchmark is problematic here. Not from the point of view of allocations, but because the actual logic is vacuous. IMO, these should be performance tests, not actual benchmarks. Alternatively, write an actual application that makes use of algebraic effects. - `maillist`: Too trivial. It's just String/list manipulation, not representative of any Haskell code we would write today (no use of base library functions which could be fused, uses String instead of Text). It's only 75 loc according to `cloc`, that's not a `real` application. Reviewers: simonpj, simonmar, bgamari, AndreasK, osa1, alpmestan, O26 nofib GHC Trac Issues: #15999 Differential Revision: https://phabricator.haskell.org/D5438 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:34:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:34:37 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.79f3a952948ff11b771f6f8694e5fd0a@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"8632268ad8405f0c01aaad3ad16e23c65771ba49/nofib" 8632268/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="8632268ad8405f0c01aaad3ad16e23c65771ba49" Stabilise benchmarks wrt. GC Summary: This is due to #15999, a follow-up on #5793 and #15357 and changes all benchmarks, some of them (i.e. `wheel-sieve1`, `awards`) rather drastically. The general plan is outlined in #15999: Identify GC-sensitive benchmarks by looking at how productivity rates change over different nursery sizes and iterate `main` of these benchmarks often enough for the non-monotony and discontinuities to go away. I was paying attention that the benchmarked logic is actually run $n times more often, rather than just benchmarking IO operations printing the result of CAFs. When I found benchmarks with insignificant runtime (#15357), I made sure that parameters/input files were adjusted so that runtime of the different modes fall within the ranges proposed in https://ghc.haskell.org/trac/ghc/ticket/15357#comment:4 - fast: 0.1-0.2s - norm: 1-2s - slow: 5-10s This is what I did: - Stabilise bernoulli - Stabilise digits-of-e1 - Stabilise digits-of-e2 - Stabilise gen_regexp - Adjust running time of integrate - Adjust running time of kahan - Stabilise paraffins - Stabilise primes - Adjust running time of rfib - Adjust running time of tak - Stabilise wheel-sieve1 - Stabilise wheel-sieve2 - Adjust running time of x2n1 - Adjust running time of ansi - Adjust running time of atom - Make awards benchmark something other than IO - Adjust running time of banner - Stabilise boyer - Adjust running time of boyer2 - Adjust running time of queens - Adjust running time of calendar - Adjust runtime of cichelli - Stabilise circsim - Stabilise clausify - Stabilise constraints with moderate success - Adjust running time of cryptarithm1 - Adjust running time of cryptarythm2 - Adjust running time of cse - Adjust running time of eliza - Adjust running time of exact-reals - Adjust running time of expert - Stabilise fft2 - Stabilise fibheaps - Stabilise fish - Adjust running time for gcd - Stabilise comp_lab_zift - Stabilise event - Stabilise fft - Stabilise genfft - Stabilise ida - Adjust running time for listcompr - Adjust running time for listcopy - Adjust running time of nucleic2 - Attempt to stabilise parstof - Stabilise sched - Stabilise solid - Adjust running time of transform - Adjust running time of typecheck - Stabilise wang - Stabilise wave4main - Adjust running time of integer - Adjust running time of knights - Stabilise lambda - Stabilise lcss - Stabilise life - Stabilise mandel - Stabilise mandel2 - Adjust running time of mate - Stabilise minimax - Adjust running time of multiplier - Adjust running time of para - Stabilise power - Adjust running time of primetest - Stabilise puzzle with mild success - Adjust running time for rewrite - Stabilise simple with mild success - Stabilise sorting - Stabilise sphere - Stabilise treejoin - Stabilise anna - Stabilise bspt - Stabilise cacheprof - Stablise compress - Stablise compress2 - Stabilise fem - Adjust running time of fluid - Stabilise fulsom - Stabilise gamteb - Stabilise gg - Stabilise grep - Adjust running time of hidden - Stabilise hpg - Stabilise infer - Stabilise lift - Stabilise linear - Attempt to stabilise maillist - Stabilise mkhprog - Stabilise parser - Stabilise pic - Stabilise prolog - Attempt to stabilise reptile - Adjust running time of rsa - Adjust running time of scs - Stabilise symalg - Stabilise veritas - Stabilise binary-trees - Adjust running time of fasta - Adjust running time of k-nucleotide - Adjust running time of pidigits - Adjust running time of reverse-complement - Adjust running time of spectral-norm - Adjust running time of fannkuch-redux - Adjust running time for n-body Problematic benchmarks: - `last-piece`: Unclear how to stabilise. Runs for 300ms and I can't make up smaller inputs because I don't understand what it does. - `pretty`: It's just much too small to be relevant at all. Maybe we want to get rid of this one? - `scc`: Same as `pretty`. The input graph for which SCC analysis is done is much too small and I can't find good directed example graphs on the internet. - `secretary`: Apparently this needs `-package random` and consequently hasn't been run for a long time. - `simple`: Same as `last-piece`. Decent runtime (70ms), but it's unstable and I see no way to iterate it ~100 times in fast mode. - `eff`: Every benchmark is problematic here. Not from the point of view of allocations, but because the actual logic is vacuous. IMO, these should be performance tests, not actual benchmarks. Alternatively, write an actual application that makes use of algebraic effects. - `maillist`: Too trivial. It's just String/list manipulation, not representative of any Haskell code we would write today (no use of base library functions which could be fused, uses String instead of Text). It's only 75 loc according to `cloc`, that's not a `real` application. Reviewers: simonpj, simonmar, bgamari, AndreasK, osa1, alpmestan, O26 nofib GHC Trac Issues: #15999 Differential Revision: https://phabricator.haskell.org/D5438 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:34:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:34:37 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.893b61176873f4bd4244ae18a7e2f3f9@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"8632268ad8405f0c01aaad3ad16e23c65771ba49/nofib" 8632268/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="8632268ad8405f0c01aaad3ad16e23c65771ba49" Stabilise benchmarks wrt. GC Summary: This is due to #15999, a follow-up on #5793 and #15357 and changes all benchmarks, some of them (i.e. `wheel-sieve1`, `awards`) rather drastically. The general plan is outlined in #15999: Identify GC-sensitive benchmarks by looking at how productivity rates change over different nursery sizes and iterate `main` of these benchmarks often enough for the non-monotony and discontinuities to go away. I was paying attention that the benchmarked logic is actually run $n times more often, rather than just benchmarking IO operations printing the result of CAFs. When I found benchmarks with insignificant runtime (#15357), I made sure that parameters/input files were adjusted so that runtime of the different modes fall within the ranges proposed in https://ghc.haskell.org/trac/ghc/ticket/15357#comment:4 - fast: 0.1-0.2s - norm: 1-2s - slow: 5-10s This is what I did: - Stabilise bernoulli - Stabilise digits-of-e1 - Stabilise digits-of-e2 - Stabilise gen_regexp - Adjust running time of integrate - Adjust running time of kahan - Stabilise paraffins - Stabilise primes - Adjust running time of rfib - Adjust running time of tak - Stabilise wheel-sieve1 - Stabilise wheel-sieve2 - Adjust running time of x2n1 - Adjust running time of ansi - Adjust running time of atom - Make awards benchmark something other than IO - Adjust running time of banner - Stabilise boyer - Adjust running time of boyer2 - Adjust running time of queens - Adjust running time of calendar - Adjust runtime of cichelli - Stabilise circsim - Stabilise clausify - Stabilise constraints with moderate success - Adjust running time of cryptarithm1 - Adjust running time of cryptarythm2 - Adjust running time of cse - Adjust running time of eliza - Adjust running time of exact-reals - Adjust running time of expert - Stabilise fft2 - Stabilise fibheaps - Stabilise fish - Adjust running time for gcd - Stabilise comp_lab_zift - Stabilise event - Stabilise fft - Stabilise genfft - Stabilise ida - Adjust running time for listcompr - Adjust running time for listcopy - Adjust running time of nucleic2 - Attempt to stabilise parstof - Stabilise sched - Stabilise solid - Adjust running time of transform - Adjust running time of typecheck - Stabilise wang - Stabilise wave4main - Adjust running time of integer - Adjust running time of knights - Stabilise lambda - Stabilise lcss - Stabilise life - Stabilise mandel - Stabilise mandel2 - Adjust running time of mate - Stabilise minimax - Adjust running time of multiplier - Adjust running time of para - Stabilise power - Adjust running time of primetest - Stabilise puzzle with mild success - Adjust running time for rewrite - Stabilise simple with mild success - Stabilise sorting - Stabilise sphere - Stabilise treejoin - Stabilise anna - Stabilise bspt - Stabilise cacheprof - Stablise compress - Stablise compress2 - Stabilise fem - Adjust running time of fluid - Stabilise fulsom - Stabilise gamteb - Stabilise gg - Stabilise grep - Adjust running time of hidden - Stabilise hpg - Stabilise infer - Stabilise lift - Stabilise linear - Attempt to stabilise maillist - Stabilise mkhprog - Stabilise parser - Stabilise pic - Stabilise prolog - Attempt to stabilise reptile - Adjust running time of rsa - Adjust running time of scs - Stabilise symalg - Stabilise veritas - Stabilise binary-trees - Adjust running time of fasta - Adjust running time of k-nucleotide - Adjust running time of pidigits - Adjust running time of reverse-complement - Adjust running time of spectral-norm - Adjust running time of fannkuch-redux - Adjust running time for n-body Problematic benchmarks: - `last-piece`: Unclear how to stabilise. Runs for 300ms and I can't make up smaller inputs because I don't understand what it does. - `pretty`: It's just much too small to be relevant at all. Maybe we want to get rid of this one? - `scc`: Same as `pretty`. The input graph for which SCC analysis is done is much too small and I can't find good directed example graphs on the internet. - `secretary`: Apparently this needs `-package random` and consequently hasn't been run for a long time. - `simple`: Same as `last-piece`. Decent runtime (70ms), but it's unstable and I see no way to iterate it ~100 times in fast mode. - `eff`: Every benchmark is problematic here. Not from the point of view of allocations, but because the actual logic is vacuous. IMO, these should be performance tests, not actual benchmarks. Alternatively, write an actual application that makes use of algebraic effects. - `maillist`: Too trivial. It's just String/list manipulation, not representative of any Haskell code we would write today (no use of base library functions which could be fused, uses String instead of Text). It's only 75 loc according to `cloc`, that's not a `real` application. Reviewers: simonpj, simonmar, bgamari, AndreasK, osa1, alpmestan, O26 nofib GHC Trac Issues: #15999 Differential Revision: https://phabricator.haskell.org/D5438 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:41:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:41:44 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.7990fd7ec5c161bec8cf45815c8c2a10@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 17:47:55 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 17:47:55 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.9d158c8b4f0a30b9f2ec35ca924a42c4@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > '''Note''' there is a shake build system attached that does a lot of this > (done by Neil Mitchell!). An explanation of it can be found here: > http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- > shake.html > > The design discussion of it is mostly lost as it was done on private > email sorry. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful (cf. #15357). > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. ~~Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful (cf. #15357)~~ done in #15999. E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. ~~Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.~~ Done, we determined that 0.1-0.2/1-2/5-10 for fast/norm/slow are the brackets to aim for. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 18:49:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 18:49:52 -0000 Subject: =?utf-8?b?W0dIQ10gIzE2MTYzOiBEb27igJl0IHRocm93IGFuIGVycm9yIChi?= =?utf-8?q?y_default=29_for_use_of_DEPRECATED_symbols_under_-Werr?= =?utf-8?q?or?= Message-ID: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Summary == Overview Don’t throw an error by default under `-Werror` when a `DEPRECATED` module, function, or type is imported or used. Use or import of a module, function, or type marked with the `WARNING` pragma will still be promoted to an error under `-Werror`. == The Idea Some “warnings” are more what you would consider “information” not and should not be considered “errors” under `-Werror` (unless explicitly requested). == Motivation Consider you’re the maintainer of a widely used library and you wish to remove some function in some later release. There is currently no way of communicating to users of your library that you plan to remove this symbol in some later major release. The natural way to express this would be to add a `DEPRECATED` pragma to the function in the next minor release, leave it there for some time horizon, and then in a following major release remove the symbol. This currently is not practical because a very large number of projects that use your library compile with `-Werror` which will then cause builds to fail //simply because you tried to alert your users of future plans//. I posit that this is broken, the crux of this is that a `DEPRECATED` //should// be considered as //info// and not a true //warning//. As it stands today, **two major releases** are required to safely deprecate (and remove) part of a public API due to the wide usage of `-Werror` which causes build failures when a new DEPRECATED pragma is added. The first major release adds the DEPRECATED pragma and the second removed the symbol or module. This discourages deprecating old APIs, introduces unnecessary version churn, and makes it more difficult to communicate to consumers of a library that an upcoming release will remove a feature. As a specific example, when attempting to align the public APIs of `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` to `HashMap.findWithDefault` to match the API of `containers`) the largest issue was how to actually deprecate the old function. The `unordered- containers` API is relatively stable and it wouldn’t warrant a new major version just to mark a function as `DEPRECATED`. You can see the discussion here (http://haskell.1045720.n5.nabble.com/Proposal-Rename- HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). = Changes == Flag Changes **Before** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. `-Wwarnings-deprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is unfortunate, imho it should be named `-Wwarnings`) `-Werror` - promote warnings to errors, including both `-Wdeprecations` and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, function, or type is imported or used. Note that //currently// there is **no distinction** between things marked as `WARNING` and things marked as `DEPRECATED` at the flag level, this is problematic. **After** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` is imported or used. `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a function, module, or type marked `WARNING` is imported or used. `-Werror` - promote warnings to errors, including `-Wwarnings- deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). (optional) `-Wwarnings` - warn if a function, module, or type marked `WARNING` is imported or used. This is a clearer flag name than `-Wwarnings-deprecations`. == Precedent for excluding warnings from being promoted to errors The idea that some things considered “warnings” are not actually “errors” already exists, specifically the flag `-Wmissed-specialisations` (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from the set of warnings that are not considered as errors. == How do I get the old behaviour back? aka. treat DEPRECATED as an error If you’re using a library and you’d like to be extra up to date and cause your build to fail if you’re using a deprecated function then you can pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` as an error. = Alternatives Considered == No change (baseline) The current state of the world as discussed in the //Motivation// section causes real issues related to natural evolution of APIs. I feel that this is not desirable in the long term. == Ask people to exclude `DEPRECATED` from `-Werror` Another option is to ask folks to not treat deprecations as errors by explicitly passing `-Wwarn=deprecations` (still requires changes to GHC since `WARNING` and `DEPRECATED` are grouped together currently). This would “fix” the problem but makes the assumption that everyone updates their build flags appropriately which is an incredibly unreasonable assumption. It also doesn’t actually address the core problem of use of deprecated APIs being treated as erroneous. = Related Work/Proposals There is an open PR to the PVP to no longer require a major version bump when a `DEPRECATED` pragma is added which has received support from both the community and members of the CLC (https://github.com/haskell/pvp/pull/18) and follows the same reasoning as here, namely that deprecating something is not meant to (and should not) break anything since it doesn’t change the API, it simply provides some information to users of the library. = Example Implementation I've put together a possible implementation of this at https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not comment on design there, keep that in the trac issue here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 19:16:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 19:16:56 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.973391e91f06452bae7c271f2f85ed5e@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by m-renaud: Old description: > = Summary > > == Overview > > Don’t throw an error by default under `-Werror` when a `DEPRECATED` > module, function, or type is imported or used. Use or import of a module, > function, or type marked with the `WARNING` pragma will still be promoted > to an error under `-Werror`. > > == The Idea > > Some “warnings” are more what you would consider “information” not and > should not be considered “errors” under `-Werror` (unless explicitly > requested). > > == Motivation > > Consider you’re the maintainer of a widely used library and you wish to > remove some function in some later release. There is currently no way of > communicating to users of your library that you plan to remove this > symbol in some later major release. The natural way to express this would > be to add a `DEPRECATED` pragma to the function in the next minor > release, leave it there for some time horizon, and then in a following > major release remove the symbol. This currently is not practical because > a very large number of projects that use your library compile with > `-Werror` which will then cause builds to fail //simply because you tried > to alert your users of future plans//. I posit that this is broken, the > crux of this is that a `DEPRECATED` //should// be considered as //info// > and not a true //warning//. > > As it stands today, **two major releases** are required to safely > deprecate (and remove) part of a public API due to the wide usage of > `-Werror` which causes build failures when a new DEPRECATED pragma is > added. The first major release adds the DEPRECATED pragma and the second > removed the symbol or module. This discourages deprecating old APIs, > introduces unnecessary version churn, and makes it more difficult to > communicate to consumers of a library that an upcoming release will > remove a feature. > As a specific example, when attempting to align the public APIs of > `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` > to `HashMap.findWithDefault` to match the API of `containers`) the > largest issue was how to actually deprecate the old function. The > `unordered-containers` API is relatively stable and it wouldn’t warrant a > new major version just to mark a function as `DEPRECATED`. You can see > the discussion here (http://haskell.1045720.n5.nabble.com/Proposal- > Rename-HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). > = Changes > == Flag Changes > **Before** > `-Wdeprecations` - warn if a module, function, or type marked > `DEPRECATED` or `WARNING` is imported or used. > `-Wwarnings-deprecations` - warn if a module, function, or type marked > `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is > unfortunate, imho it should be named `-Wwarnings`) > `-Werror` - promote warnings to errors, including both `-Wdeprecations` > and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, > function, or type is imported or used. > > Note that //currently// there is **no distinction** between things marked > as `WARNING` and things marked as `DEPRECATED` at the flag level, this is > problematic. > > **After** > `-Wdeprecations` - warn if a module, function, or type marked > `DEPRECATED` is imported or used. > `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a > function, module, or type marked `WARNING` is imported or used. > `-Werror` - promote warnings to errors, including `-Wwarnings- > deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). > (optional) `-Wwarnings` - warn if a function, module, or type marked > `WARNING` is imported or used. This is a clearer flag name than > `-Wwarnings-deprecations`. > > == Precedent for excluding warnings from being promoted to errors > The idea that some things considered “warnings” are not actually “errors” > already exists, specifically the flag `-Wmissed-specialisations` > (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- > warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from > the set of warnings that are not considered as errors. > > == How do I get the old behaviour back? aka. treat DEPRECATED as an error > If you’re using a library and you’d like to be extra up to date and cause > your build to fail if you’re using a deprecated function then you can > pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` > as an error. > > = Alternatives Considered > == No change (baseline) > The current state of the world as discussed in the //Motivation// section > causes real issues related to natural evolution of APIs. I feel that this > is not desirable in the long term. > > == Ask people to exclude `DEPRECATED` from `-Werror` > Another option is to ask folks to not treat deprecations as errors by > explicitly passing `-Wwarn=deprecations` (still requires changes to GHC > since `WARNING` and `DEPRECATED` are grouped together currently). This > would “fix” the problem but makes the assumption that everyone updates > their build flags appropriately which is an incredibly unreasonable > assumption. It also doesn’t actually address the core problem of use of > deprecated APIs being treated as erroneous. > > = Related Work/Proposals > There is an open PR to the PVP to no longer require a major version bump > when a `DEPRECATED` pragma is added which has received support from both > the community and members of the CLC > (https://github.com/haskell/pvp/pull/18) and follows the same reasoning > as here, namely that deprecating something is not meant to (and should > not) break anything since it doesn’t change the API, it simply provides > some information to users of the library. > > = Example Implementation > I've put together a possible implementation of this at > https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not > comment on design there, keep that in the trac issue here. New description: = Summary == Overview Don’t throw an error by default under `-Werror` when a `DEPRECATED` module, function, or type is imported or used. Use or import of a module, function, or type marked with the `WARNING` pragma will still be promoted to an error under `-Werror`. == The Idea Some “warnings” are more what you would consider “information” and should not be considered “errors” under `-Werror` (unless explicitly requested). == Motivation Consider you’re the maintainer of a widely used library and you wish to remove some function in some later release. There is currently no way of communicating to users of your library that you plan to remove this symbol in some later major release. The natural way to express this would be to add a `DEPRECATED` pragma to the function in the next minor release, leave it there for some time horizon, and then in a following major release remove the symbol. This currently is not practical because a very large number of projects that use your library compile with `-Werror` which will then cause builds to fail //simply because you tried to alert your users of future plans//. I posit that this is broken, the crux of this is that a `DEPRECATED` //should// be considered as //info// and not a true //warning//. As it stands today, **two major releases** are required to safely deprecate (and remove) part of a public API due to the wide usage of `-Werror` which causes build failures when a new DEPRECATED pragma is added. The first major release adds the DEPRECATED pragma and the second removed the symbol or module. This discourages deprecating old APIs, introduces unnecessary version churn, and makes it more difficult to communicate to consumers of a library that an upcoming release will remove a feature. As a specific example, when attempting to align the public APIs of `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` to `HashMap.findWithDefault` to match the API of `containers`) the largest issue was how to actually deprecate the old function. The `unordered- containers` API is relatively stable and it wouldn’t warrant a new major version just to mark a function as `DEPRECATED`. You can see the discussion here (http://haskell.1045720.n5.nabble.com/Proposal-Rename- HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). = Changes == Flag Changes **Before** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. `-Wwarnings-deprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is unfortunate, imho it should be named `-Wwarnings`) `-Werror` - promote warnings to errors, including both `-Wdeprecations` and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, function, or type is imported or used. Note that //currently// there is **no distinction** between things marked as `WARNING` and things marked as `DEPRECATED` at the flag level, this is problematic. **After** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` is imported or used. `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a function, module, or type marked `WARNING` is imported or used. `-Werror` - promote warnings to errors, including `-Wwarnings- deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). (optional) `-Wwarnings` - warn if a function, module, or type marked `WARNING` is imported or used. This is a clearer flag name than `-Wwarnings-deprecations`. == Precedent for excluding warnings from being promoted to errors The idea that some things considered “warnings” are not actually “errors” already exists, specifically the flag `-Wmissed-specialisations` (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from the set of warnings that are not considered as errors. == How do I get the old behaviour back? aka. treat DEPRECATED as an error If you’re using a library and you’d like to be extra up to date and cause your build to fail if you’re using a deprecated function then you can pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` as an error. = Alternatives Considered == No change (baseline) The current state of the world as discussed in the //Motivation// section causes real issues related to natural evolution of APIs. I feel that this is not desirable in the long term. == Ask people to exclude `DEPRECATED` from `-Werror` Another option is to ask folks to not treat deprecations as errors by explicitly passing `-Wwarn=deprecations` (still requires changes to GHC since `WARNING` and `DEPRECATED` are grouped together currently). This would “fix” the problem but makes the assumption that everyone updates their build flags appropriately which is an incredibly unreasonable assumption. It also doesn’t actually address the core problem of use of deprecated APIs being treated as erroneous. = Related Work/Proposals There is an open PR to the PVP to no longer require a major version bump when a `DEPRECATED` pragma is added which has received support from both the community and members of the CLC (https://github.com/haskell/pvp/pull/18) and follows the same reasoning as here, namely that deprecating something is not meant to (and should not) break anything since it doesn’t change the API, it simply provides some information to users of the library. = Example Implementation I've put together a possible implementation of this at https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not comment on design there, keep that in the trac issue here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 21:28:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 21:28:11 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.260510adc9909d1b7cd3417b40ca3572@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by m-renaud: Old description: > = Summary > > == Overview > > Don’t throw an error by default under `-Werror` when a `DEPRECATED` > module, function, or type is imported or used. Use or import of a module, > function, or type marked with the `WARNING` pragma will still be promoted > to an error under `-Werror`. > > == The Idea > > Some “warnings” are more what you would consider “information” and should > not be considered “errors” under `-Werror` (unless explicitly requested). > > == Motivation > > Consider you’re the maintainer of a widely used library and you wish to > remove some function in some later release. There is currently no way of > communicating to users of your library that you plan to remove this > symbol in some later major release. The natural way to express this would > be to add a `DEPRECATED` pragma to the function in the next minor > release, leave it there for some time horizon, and then in a following > major release remove the symbol. This currently is not practical because > a very large number of projects that use your library compile with > `-Werror` which will then cause builds to fail //simply because you tried > to alert your users of future plans//. I posit that this is broken, the > crux of this is that a `DEPRECATED` //should// be considered as //info// > and not a true //warning//. > > As it stands today, **two major releases** are required to safely > deprecate (and remove) part of a public API due to the wide usage of > `-Werror` which causes build failures when a new DEPRECATED pragma is > added. The first major release adds the DEPRECATED pragma and the second > removed the symbol or module. This discourages deprecating old APIs, > introduces unnecessary version churn, and makes it more difficult to > communicate to consumers of a library that an upcoming release will > remove a feature. > As a specific example, when attempting to align the public APIs of > `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` > to `HashMap.findWithDefault` to match the API of `containers`) the > largest issue was how to actually deprecate the old function. The > `unordered-containers` API is relatively stable and it wouldn’t warrant a > new major version just to mark a function as `DEPRECATED`. You can see > the discussion here (http://haskell.1045720.n5.nabble.com/Proposal- > Rename-HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). > = Changes > == Flag Changes > **Before** > `-Wdeprecations` - warn if a module, function, or type marked > `DEPRECATED` or `WARNING` is imported or used. > `-Wwarnings-deprecations` - warn if a module, function, or type marked > `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is > unfortunate, imho it should be named `-Wwarnings`) > `-Werror` - promote warnings to errors, including both `-Wdeprecations` > and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, > function, or type is imported or used. > > Note that //currently// there is **no distinction** between things marked > as `WARNING` and things marked as `DEPRECATED` at the flag level, this is > problematic. > > **After** > `-Wdeprecations` - warn if a module, function, or type marked > `DEPRECATED` is imported or used. > `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a > function, module, or type marked `WARNING` is imported or used. > `-Werror` - promote warnings to errors, including `-Wwarnings- > deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). > (optional) `-Wwarnings` - warn if a function, module, or type marked > `WARNING` is imported or used. This is a clearer flag name than > `-Wwarnings-deprecations`. > > == Precedent for excluding warnings from being promoted to errors > The idea that some things considered “warnings” are not actually “errors” > already exists, specifically the flag `-Wmissed-specialisations` > (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- > warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from > the set of warnings that are not considered as errors. > > == How do I get the old behaviour back? aka. treat DEPRECATED as an error > If you’re using a library and you’d like to be extra up to date and cause > your build to fail if you’re using a deprecated function then you can > pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` > as an error. > > = Alternatives Considered > == No change (baseline) > The current state of the world as discussed in the //Motivation// section > causes real issues related to natural evolution of APIs. I feel that this > is not desirable in the long term. > > == Ask people to exclude `DEPRECATED` from `-Werror` > Another option is to ask folks to not treat deprecations as errors by > explicitly passing `-Wwarn=deprecations` (still requires changes to GHC > since `WARNING` and `DEPRECATED` are grouped together currently). This > would “fix” the problem but makes the assumption that everyone updates > their build flags appropriately which is an incredibly unreasonable > assumption. It also doesn’t actually address the core problem of use of > deprecated APIs being treated as erroneous. > > = Related Work/Proposals > There is an open PR to the PVP to no longer require a major version bump > when a `DEPRECATED` pragma is added which has received support from both > the community and members of the CLC > (https://github.com/haskell/pvp/pull/18) and follows the same reasoning > as here, namely that deprecating something is not meant to (and should > not) break anything since it doesn’t change the API, it simply provides > some information to users of the library. > > = Example Implementation > I've put together a possible implementation of this at > https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not > comment on design there, keep that in the trac issue here. New description: = Summary == Overview Don’t throw an error by default under `-Werror` when a `DEPRECATED` module, function, or type is imported or used. Use or import of a module, function, or type marked with the `WARNING` pragma will still be promoted to an error under `-Werror`. == The Idea Some “warnings” are more what you would consider “information” and should not be considered “errors” under `-Werror` (unless explicitly requested). == Motivation Consider you’re the maintainer of a widely used library and you wish to remove some function in some later release. There is currently no way of communicating to users of your library that you plan to remove this symbol in some later major release. The natural way to express this would be to add a `DEPRECATED` pragma to the function in the next minor release, leave it there for some time horizon, and then in a following major release remove the symbol. This currently is not practical because a very large number of projects that use your library compile with `-Werror` which will then cause builds to fail //simply because you tried to alert your users of future plans//. I posit that this is broken, the crux of this is that a `DEPRECATED` //should// be considered as //info// and not a true //warning//. As it stands today, **two major releases** are required to safely deprecate (and remove) part of a public API due to the wide usage of `-Werror` which causes build failures when a new DEPRECATED pragma is added. The first major release adds the DEPRECATED pragma and the second removed the symbol or module. This discourages deprecating old APIs, introduces unnecessary version churn, and makes it more difficult to communicate to consumers of a library that an upcoming release will remove a feature. As a specific example, when attempting to align the public APIs of `containers` and `unordered-containers` (renaming `HashMap.lookupDefault` to `HashMap.findWithDefault` to match the API of `containers`) the largest issue was how to actually deprecate the old function. The `unordered- containers` API is relatively stable and it wouldn’t warrant a new major version just to mark a function as `DEPRECATED`. You can see the discussion here (http://haskell.1045720.n5.nabble.com/Proposal-Rename- HashMap-lookupDefault-to-HashMap-findWithDefault-td5870348.html). = Changes == Flag Changes **Before** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. `-Wwarnings-deprecations` - warn if a module, function, or type marked `DEPRECATED` or `WARNING` is imported or used. (The name of this flag is unfortunate, imho it should be named `-Wwarnings`) `-Werror` - promote warnings to errors, including both `-Wdeprecations` and `-Wwarnings`. In other words, if a `DEPRECATED` or `WARNING` module, function, or type is imported or used. Note that //currently// there is **no distinction** between things marked as `WARNING` and things marked as `DEPRECATED` at the flag level, this is problematic. **After** `-Wdeprecations` - warn if a module, function, or type marked `DEPRECATED` is imported or used. `-Wwarnings-deprecations` (or rename to `-Wwarnings`) - warn if a function, module, or type marked `WARNING` is imported or used. `-Werror` - promote warnings to errors, including `-Wwarnings- deprecations` (`WARNING`), **but not** `-Wdeprecations` (`DEPRECATED`). (optional) `-Wwarnings` - warn if a function, module, or type marked `WARNING` is imported or used. This is a clearer flag name than `-Wwarnings-deprecations`. == Precedent for excluding warnings from being promoted to errors The idea that some things considered “warnings” are not actually “errors” already exists, specifically the flag `-Wmissed-specialisations` (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wmissed-specialisations) is already excluded from the set of warnings that are not considered as errors. == How do I get the old behaviour back? aka. treat DEPRECATED as an error If you’re using a library and you’d like to be extra up to date and cause your build to fail if you’re using a deprecated function then you can pass `-Werror=deprecations` to GHC and it will treat use of `DEPRECATED` as an error. = Alternatives Considered == No change (baseline) The current state of the world as discussed in the //Motivation// section causes real issues related to natural evolution of APIs. I feel that this is not desirable in the long term. == Ask people to exclude `DEPRECATED` from `-Werror` Another option is to ask folks to not treat deprecations as errors by explicitly passing `-Wwarn=deprecations` (still requires changes to GHC since `WARNING` and `DEPRECATED` are grouped together currently). This would “fix” the problem but makes the assumption that everyone updates their build flags appropriately which is an incredibly unreasonable assumption. It also doesn’t actually address the core problem of use of deprecated APIs being treated as erroneous. = Related Work/Proposals There is an open PR to the PVP to no longer require a major version bump when a `DEPRECATED` pragma is added which has received support from both the community and members of the CLC (https://github.com/haskell/pvp/pull/18) and follows the same reasoning as here, namely that deprecating something is not meant to (and should not) break anything since it doesn’t change the API, it simply provides some information to users of the library. = Example Implementation I've put together a possible implementation of this at https://gitlab.haskell.org/ghc/ghc/merge_requests/89, but please do not comment on design there, keep that in the trac issue here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 21:41:49 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 21:41:49 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.cd94fa36bdb32baf71645514c491b45b@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): I ran a vanilla build of on a fresh Windows instance and saw the following failures: {{{ Unexpected results from: TEST="T15904 plugin-recomp-flags plugin-recomp-impure plugins09 plugins10 plugins11" SUMMARY for test run started at 01/09/19 21:10:29 Greenwich Standard Time 0:14:31 spent to go through 23 total tests, which gave rise to 67 test cases, of which 32 were skipped 0 had missing libraries 29 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 6 unexpected failures 0 unexpected stat failures Unexpected failures: hp2ps/T15904.run T15904 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins10.run plugins10 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad stdout] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) }}} Consequently I suspect few of these failures real. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 21:44:57 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 21:44:57 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.f1eb93e42fc4a364f2ad3f134746934c@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Here is a simple MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/99 Neil: As you can see, I switched to the untracked version of `getDirectoryFiles`, because GMP object files are generated. However, this does not fix the Lint failure. I am a bit lost: I don't know how we could possibly touch these object files again. We unpack the archive with these objects. We then use `getDirectoryFiles` to get the list of objects, and need it when building the `integer-gmp` library. Do you have any ideas how we could possibly mess this up? I have a suspicion that this is a Lint bug, but I couldn't reproduce it on a small example. Until we figure out how to fix this, I think we'll need to drop the flag `--lint` when invoking Hadrian, to prevent CI bots from failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 22:52:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 22:52:42 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.9bfdee00e6c3a7e9ca80e7c6663b3cac@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) Comment: `shiftL` is ''not'' supposed to be called with a negative number of bits (that's what `shift` is for). It's documented in the Haddock for `shiftL`: > Shift the argument left by the specified number of bits (which must be non-negative). Without any heavy optimizations, `shiftL 1 hm` turns into `shiftL#` turns into the `uncheckedShiftL#` primop, which explicitly says that a negative number of bits produces undefined output. I suspect it is nonetheless usually deterministic, hence the `True` outputs. On `-O2`, we'll trigger the `uncheckedShiftL#` builtin rule. That rule takes one look at the negative shift bits and decides to "optimize" this into a runtime error that prints out `"Bad shift length"` and the shift length. The only case that isn't yet covered is the `-O1 -fllvm` case. It's likely that the LLVM call we produce for `uncheckedShiftL#` also has undefined behaviour for negative shift values, and LLVM applies some more optimizations ultimately resulting in the `False` output. ---- This looks like a bad API: we really should have `shiftL :: a -> Word -> a` instead of `shiftL :: a -> Int -> a` (and same for `shiftR`). Instead of stomaching that breakage, we could also just add an extra check to the `Word`, `Int`, etc. instances of `shiftL` to guard against negative inputs: {{{ instance Bits Word where {- snipped -} (W# x#) `shift` (I# i#) | isTrue# (i# >=# 0#) = W# (x# `shiftL#` i#) | otherwise = W# (x# `shiftRL#` negateInt# i#) (W# x#) `shiftL` (I# i#) | isTrue# (i# >=# 0#) = W# (x# `shiftL#` i#) | otherwise = error "shiftL: expected non-negative number of bits" }}} Or even: deprecate `shiftL`/`shiftR` entirely in favour of `shift` (and let the default definitions, which fall back to the safer `shift`, take effect). Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 23:05:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 23:05:47 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.64ba4e7777319a60d81f634bd6cfcc86@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Actually, given that Haskell report defines `shiftL` and `shiftR`, changing their types or deprecating them is definitely not a good idea... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 23:29:15 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 23:29:15 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.bd2cae405ed8013f89fb9f3620a434f5@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Without knowing anything about the implementation details of `shiftL`/`shiftR`, my hope would be that invoking them with a negative number of bits would throw an exception, regardless of the optimization level. I could certainly envision that an unsafe primop like `uncheckedShiftL#` would have undefined behavior if given a negative number of bits as an argument, but it feels like we should be able to do better for `shiftL`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 9 23:59:26 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Jan 2019 23:59:26 -0000 Subject: [GHC] #16091: arith011 broken with integer-simple In-Reply-To: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> References: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> Message-ID: <061.570fc76ef29e73813ab559786778ebaa@haskell.org> #16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/36 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 00:30:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 00:30:16 -0000 Subject: [GHC] #15982: Hadrian's `--configure` flag is broken on Windows In-Reply-To: <050.1db3a576777b406081d2912367d7ba45@haskell.org> References: <050.1db3a576777b406081d2912367d7ba45@haskell.org> Message-ID: <065.783ff02e6bb98d657c064c8b771b8925@haskell.org> #15982: Hadrian's `--configure` flag is broken on Windows -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I propose to switch to the Cabal build script by default, at least until this ticket is resolved: https://gitlab.haskell.org/ghc/ghc/merge_requests/100 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 03:51:08 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 03:51:08 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.130f964adba128100a09bbd9a15fda0c@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm pleased to report that we have singletons [https://github.com/goldfirere/singletons/issues/357#issuecomment-452935291 working again], but it will require users to write apparently-redundant type annotations in a few places. It would be nice to address this bug / design flaw so that singletons can become more ergonomic again. (Yes, I know this will have to go through the proposals process, but I still would like feedback here first.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 07:03:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 07:03:04 -0000 Subject: [GHC] #16164: Provide bitreverse primop Message-ID: <047.f3aae0f1a192ff22dd51ddc4f1892d2e@haskell.org> #16164: Provide bitreverse primop -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We already have nice primops like {{{byteSwap#}}}, it'd be nice to also have {{{bitreverse}}}. Clang provides {{{__builtin_bitreverse}}} (http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse) functions which could be the default. GCC currently doesn't have a built- in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481). One prominent place where this primop could be used is Data.IntSet.Internal where it's implemented as a {{{revNat}}}. Many other libraries also define own versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 07:03:48 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 07:03:48 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.8d686e96ff089045fd3bff6c3038d928@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): In the process of finalising the ticket. Working on test failures and adding an additional test. Shouldn't be too long now :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 07:18:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 07:18:17 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.b86e1080718b322e83c77eead78f700d@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): I am not sure that the proposed change is really an improvement: If I use `-Werror` in the flags for my package, I want to be notified of every tiny problem in my code and basically promise to fix to those problems quickly. Probably my build system/CI even depends on the fact that those problems result in failed build, otherwise one would have to wade through large log files etc. If that's not what is intended, `-Wall` is probably the right flag to use, not `-Werror`. The main problem is the IMHO questionable change that adding `DEPRECATED` pragmas should not require a major version bump. I don't really buy into the artificial distinction between "information" and "warnings", both hint at potential problems. Just my 2c... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 08:07:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 08:07:16 -0000 Subject: [GHC] #16143: Some cost centre stacks are not registered via registerCcsList() In-Reply-To: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> References: <043.18a1d8fc1faa62c231078d044bebc356@haskell.org> Message-ID: <058.441583462ea663911fea9e7382c70fb2@haskell.org> #16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 Comment: I'll document this stuff before closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 08:13:28 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 08:13:28 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.43326de8e2f1899feb34662ae9c90455@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): Found another bug. In RaiseAsync.c: {{{ -- RaiseAsync.c:924 SET_HDR(ap,&stg_AP_STACK_NOUPD_info, ((StgClosure *)frame)->header.prof.ccs /* ToDo */); }}} We're reading CCS of an underflow frame, but underflow frames do not have profiling headers: {{{ typedef struct { const StgInfoTable* info; struct StgStack_ *next_chunk; } StgUnderflowFrame; }}} I also checked other stack frame definitions in `Closures.h`. Most of them have a proper header (`StgHeader`), except `StgUnderflowFrame` and `StgRetFun`. Simon, should we add proper headers to these frames or is the bug in somewhere else? I'm not sure when should a stack frame has a proper header (that includes profiling stuff in profiling builds) vs. just a info ptr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 08:59:10 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 08:59:10 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.09199aed300162c91447f53139ff39c8@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): MR at https://gitlab.haskell.org/ghc/ghc/merge_requests/103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 09:03:35 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 09:03:35 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.086fb0e7180561f27e46e9700e4ebea0@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): '''Forall-or-nothing behaviour''' > Another interesting example has cropped up. Re-consider Partial type signatures have always had the semantics that you can use a `forall` to bind the type variables you need to mention but the final type signature may have more. E.g. {{{ f :: forall a. _ -> a -> Bool f x y = True }}} Here the final sig is `f :: forall a b. b -> a -> Bool`. It would be possible to say that * If you use a `forall` there must be no more quantifiers (except, `Inferred` ones?), or * There can be extra quantifiers, but they are `Inferred`, so we'd get `f :: forall {b}. forall a. b -> a -> Bool`. (I quite like this.), or * The current behaviour. I don't feel strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 09:06:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 09:06:51 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.82492d5f211c18b2e6ae69be51958277@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): '''Let-must-not-be-generalised''' behaviour > Because GHC does not respect let-should-not-be-generalized in the presence of partial type signatures, this is rejected again. It's hard to see how GHC ''could'' respect let-should-not-be-generalised. Consider {{{ f :: forall a. _ -> a f = e }}} How could we check this signature without generalising the type of `e`? I suppose there could be a special case if there is no user-written `forall`. So `f :: forall. blah` means "please generalise` and `f :: blah` means "don't generalise". But that's in conflict with some of the choices under "forall-or-nothing" above. Regardless, it'd be good to document the behaviour in the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 09:50:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 09:50:38 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.f975837ce5a61eb8e33a8eecf65dfe6e@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): The correctness criteria for getDirectoryFiles is nuanced - and you're actually obeying it - I just write a much simpler "no generated files" one in the docs because that's a reasonable safe approximation. As a result, I'm not surprised your change doesn't help. What we are observing is the modification time changes. I know that on some file systems (e.g. NFS) the modification time is cached at a different resolution from the resolution it is stored on disk. Is there a chance we're hitting this? If so, the only current options are to disable lint checking (which is probably fine - maybe leave it on for your dev work) or disable use of modification times (which will slow down rechecking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 10:49:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 10:49:38 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.2d7d2e1f7248a7303a6d94cdb2d34cb6@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D5051 (reverted), Phab:D5165, Phab:D5178 => Phab:D5051 (reverted), Phab:D5165, Phab:D5178, MR:103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 14:19:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 14:19:15 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.09fd3ad1024a9c775df572d76a421401@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Running {{{make install}}} on powerpc64 throws error: {{{ghc-cabal: '/usr/local/lib/ghc-8.6.3/bin/ghc-pkg' exited with an error: array-0.5.3.0: Warning: haddock-interfaces: /usr/local/share/doc/ghc-8.6.3/html/libraries/array-0.5.3.0/array.haddock doesn't exist or isn't a file array-0.5.3.0: dependency "base-4.12.0.0" doesn't exist (use --force to override)}}} Still, {{{ghc}}} binary was installed, and it works. When i had {{{DYNAMIC_GHC_PROGRAMS=YES}}}, I used the script from {{{bin/ghc}}}, but it threw the same error. It works with it disabled. When {{{DYNAMIC_GHC_PROGRAMS=YES}}}, {{{inplace/bin/ghc-stage2}}} is not present. {{{ghc-stage2}}} is in {{{ghc/stage2/build/tmp}}}: {{{ root at talos:$/home/pkubaj/ghc-8.6.3-boot$ find . -name ghc-stage2 ./ghc/stage2/build/tmp/ghc-stage2 }}} This binary seems to run ok. {{{ root at talos:$/home/pkubaj/ghc-8.6.3-boot$ ./ghc/stage2/build/tmp/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 15:34:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 15:34:23 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.93c59d4577b41783e00db5ee439515db@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/110 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/110 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 15:36:49 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 15:36:49 -0000 Subject: [GHC] #7026: Impredicative implicit parameters In-Reply-To: <053.25b259461b9982823509f8610b588780@haskell.org> References: <053.25b259461b9982823509f8610b588780@haskell.org> Message-ID: <068.0abe99c51274dd7e06dec7f00633db56@haskell.org> #7026: Impredicative implicit parameters -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 15:45:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 15:45:27 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.02e355c5e8846eb4c20ea957b9b223af@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 16059 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 16059 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 16:13:43 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 16:13:43 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.a8575b3ab0271f5bfe81a8a74e763169@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Consider these three possible type signatures for `id`: {{{ id x = x }}} 1. `id :: forall a. a -> a`: the most general type 2. `id :: Int -> Int`: not the most general type, by any means, but accepted without warnng. 3. `id :: Num a => a -> a`: not the most general type, although more general than `Int -> Int`. Elicits a redundant constraint warning. Arguably, it's odd that (2) is accepted without complaint, whereas (3) elicits a warning. Still, in the case of `id` there is no reason to prefer (3) over (1). But your example shows that it is, in fact, sometimes desirable to have a constraint that is not used (as in `id`). Here is a small contrived example: {{{ -- f :: (a ~ Bool) => a -> Int f :: a -> Int f x = 3 g :: String -> Int g s = f (read s) }}} Here the type of `y` is unconstrained, but we need to know what it is to resolve the Read constraint. If `f :: a -> Int`, there is no way to resolve the ambiguity, so we get {{{ Foo.hs:38:10: error: • Ambiguous type variable ‘a0’ arising from a use of ‘read’ prevents the constraint ‘(Read a0)’ from being solved. }}} But if we give `f` the signature `f :: (a ~ Bool) => a -> Int`,the ambiguity goes away; it is resolved to `Bool`. But instead we get {{{ Foo.hs:33:1: warning: [-Wredundant-constraints] • Redundant constraint: a ~ Bool • In the type signature for: f :: forall a. (a ~ Bool) => a -> Int | 33 | f :: (a ~ Bool) => a -> Int | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Your example is similar, but a little more complicated. I'm not sure what to say. The constraint ''is'' redundant for `f`'s definition. And yet a less-general (more constrained) type can aid the caller. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 16:36:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 16:36:25 -0000 Subject: [GHC] #16151: GHC 8.6 build failure on ARM In-Reply-To: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> References: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> Message-ID: <060.591efbd8d8f5a6b3ecf47924fade5dc4@haskell.org> #16151: GHC 8.6 build failure on ARM ----------------------------------------+------------------------------ Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by dustin): * Attachment "Dockerfile" added. Dockerfile for building an ARM build environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 16:42:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 16:42:39 -0000 Subject: [GHC] #16151: GHC 8.6 build failure on ARM In-Reply-To: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> References: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> Message-ID: <060.7905ba82a6f677582a4e2a1d671d8df7@haskell.org> #16151: GHC 8.6 build failure on ARM ----------------------------------------+------------------------------ Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by dustin): I've attached the Docker file I used to successfully build the 8.6 branch on ARM. {{{ ghc at 76bbfcc338d8:~/ghc$ /usr/local/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 }}} It's based on one of the CI dockerfiles, with no material changes. Note that it doesn't include teTeX -- I did build a docker image with that successfully (and it's massive) so it's possible, but I didn't have that enabled when I did my final build. One thing in particular that is important for my environment, but perhaps not in general is that I'm using my own clang binary distribution. I'm running on PC Linux and have some userid mapping stuff and there's a mess of UID mapping with the clang distribution having a strange user ID that I don't want to configure my system around. I just changed the user ID in my tar file and renamed the files while I was at it so it would install into the correct place (also saving a bit of time). Is there a path to official binary distributions from this? I don't expect to be trusted (at least, not at this point), but it would be nice if ghc were available to everyone. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 16:59:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 16:59:07 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian In-Reply-To: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> Message-ID: <065.cfcdb60cc76322c85f6f2766b9bda5b3@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/107 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/107 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 17:08:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 17:08:41 -0000 Subject: [GHC] #16165: Move Hadrian (github) wiki information to in-tree docs Message-ID: <048.5b06e11b390b512445d9d7aef2617a03@haskell.org> #16165: Move Hadrian (github) wiki information to in-tree docs -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://github.com/snowleopard/hadrian/wiki contains useful information about debugging/testing/profiling Hadrian. We definitely want to move this in the source tree. I'll take care of this in the upcoming weeks (this is not the most urgent Hadrian task, to be honest), unless someone beats me to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 18:46:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 18:46:42 -0000 Subject: [GHC] #16118: SYB link in Data.Data is dead In-Reply-To: <045.8bbd8a67c43b7423e7fe4ecadaf4cfc6@haskell.org> References: <045.8bbd8a67c43b7423e7fe4ecadaf4cfc6@haskell.org> Message-ID: <060.20ae69c152a8d2507ec7ea2bb2db46c9@haskell.org> #16118: SYB link in Data.Data is dead -------------------------------------+------------------------------------- Reporter: ocramz | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The question of course is what we should do about this. Linking to an archive.org mirror from Haddocks doesn't seem like a great idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 19:27:49 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 19:27:49 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.e3f4fa2a495413352287708815a3d1e4@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of gathering more examples, this also manifests when checking unboxed tuples. For instance, GHC compiles `B.hs` below successfully, even though it shouldn't (since the `UnboxedTuples` extension isn't enabled in `B`): {{{#!hs {-# LANGUAGE UnboxedTuples #-} module A where type Foo = (# #) }}} {{{#!hs -- B.hs module B where import A type Bar = Foo }}} On the other hand, in `C.hs` below: {{{#!hs -- C.hs {-# LANGUAGE TemplateHaskell #-} module C where import Language.Haskell.TH (conT, unboxedTupleTypeName) type Baz = $(conT (unboxedTupleTypeName 0)) }}} GHC correctly rejects this, since there's no intermediate type synonym: {{{ C.hs:7:1: error: • Illegal unboxed tuple type as function argument: (# #) Perhaps you intended to use UnboxedTuples • In the type synonym declaration for ‘Baz’ | 7 | type Baz = $(conT (unboxedTupleTypeName 0)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} ----- This also affects `RankNTypes`, since `B.hs` is erroneously accepted: {{{#!hs -- A.hs {-# LANGUAGE RankNTypes #-} module A where type Foo = forall a. a }}} {{{#!hs -- B.hs module B where import A f :: Foo -> b -> b f g x = g x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 20:05:19 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 20:05:19 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.d98f65d3b06bf7940ba86b1ce68483ad@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It turns out that option (1) from comment:4 is just plain infeasible. If you implement it, then several test cases that should fail suddenly pass. `tcfail129` is one example: {{{#!hs module ShouldFail where data T = T -- This was erroneously accepted type Foo a = String -> Maybe a type Bar m = m Int blah = undefined :: Bar Foo type Foo1 a = Maybe a type Bar1 m = m Int blah1 = undefined :: Bar1 Foo1 }}} This should fail due to the unsaturated use of `Foo`/`Foo1`, but if we always expand, then we'll never catch that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 22:03:47 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 22:03:47 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.b36b6a49a68301f1f77ee19cdbe8f5ef@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/112 Comment: Option (3) from comment:4 ended up being just the ticket to fixing this bug. See https://gitlab.haskell.org/ghc/ghc/merge_requests/112. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 22:48:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 22:48:15 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.4c3d6710914974a108fcd230d2993ffe@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks Neil! I disabled the Lint for now. In fact, having it enabled all the time is probably unnecessary, since it takes up a little bit of time each run. Hadrian developers can pass `--lint` if need be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 10 23:35:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Jan 2019 23:35:12 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.f9d81133eba2e6a1729ec1c97b9cc51a@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): I am opposed to this. I see no benefit, and agree with most of the criticism posted on reddit. Users of -Werror typically have the mindset that they want warningless code - because whichever warning flags they have enabled in tandem with -Werror are serving as guards against poor code. If they don't have this mindset, then I don't understand why they'd use -Werror. Deprecations happen, and things will break because of it. I don't agree with the lounging about on the issue on unordered-containers you mention because of breaking -Werror builds (I think anyone using -Werror ought to care enough to adapt to deprecations!), but I also don't think there should be any exceptions to -Werror. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 01:21:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 01:21:37 -0000 Subject: [GHC] #15948: Hadrian build fails on Windows when invoked without --configure flag In-Reply-To: <046.fad7028de08314594b0d21c085af049c@haskell.org> References: <046.fad7028de08314594b0d21c085af049c@haskell.org> Message-ID: <061.da13ffa75a78568987d005fa8b013430@haskell.org> #15948: Hadrian build fails on Windows when invoked without --configure flag -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I got bitten by this as well. We probably want to fix this sometimes this month, as I suspect most/all Windows users will be bitten by this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 01:58:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 01:58:23 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.c38e4970f12a91accd86058953221363@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by m-renaud): Thank you for the feedback! I completely agree with the concerns raised here, I just posted a comment to the Reddit thread[1] that clarifies how this proposal fits into to the issue I'm trying to address (which I should have made more/clear prominent in this proposal). In summary (see linked thread for more details), the main problem I'm trying to solve is the lack of policy/clarity around deprecating APIs, specifically that anything that causes a breakage under `-Werror` requires a major version bump. This can either be addressed by a policy change, or a code/behaviour change (this proposal). Having both in hand you can compare the pros/cons of each instead of talking about "some proposal that could exist" in the abstract. I personally would prefer a policy change, in which case this proposal would become obsolete. There's also the fact that I should have broken this into two: A. differentiate between `DEPRECATED` and `WARNING` at the flag level (currently they're conflated). And B. which changes the behaviour of `-Werror`. I think (A) is non-controversial (and should probably be done anyways?), (B) is the controversial part since its a change in behaviour. Let me know your thoughts, as well as if you would be in favour of the policy change instead of this proposal. Thanks! [1] https://www.reddit.com/r/haskell/comments/aelbv7/rfc_ghc_proposal_dont_throw_an_error_by_default/edrjt5n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 02:15:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 02:15:30 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.67b7c49bb09c78b1ac9324adc2b497cf@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => MR:97 Comment: The Phab patch is migrated to https://gitlab.haskell.org/ghc/ghc/merge_requests/97. I also added a test for this ticket there so I'm officially making it a fix for this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 02:16:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 02:16:56 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.bb742d1aa72029565297aeea4673af98@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I reverted ddb870bf7055ccc8ff8b86c161f31aad81d01add in https://gitlab.haskell.org/ghc/ghc/merge_requests/97, which fixes the difference between `x = ...` and `let x = ...` in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 02:46:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 02:46:24 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.a821af65960160829f73f5f2b83e76fa@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => MR:97 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 02:48:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 02:48:33 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.4a16e4bc4acee09bb55efb0b03739f05@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: infoneeded => patch * differential: => MR:97 Comment: Even if there's still a bug here it'll be fixed with MR:97 where we treat `x = y` as `let x = y`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 03:36:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 03:36:15 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.0d779ff0ddde02d4b888c10cb9a3cffc@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => upstream Comment: As noted in https://gitlab.haskell.org/ghc/ghc/merge_requests/112#note_2409, the MR I linked to above is failing to validate due to a sneaky use of impredicativity in `Cabal` that went unnoticed until this patch revealed it. I've opened a `Cabal` issue upstream [https://github.com/haskell/cabal/issues/5833 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 05:59:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 05:59:01 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors Message-ID: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've attached code that is a drastically trimmed down version of the `warp` library, which depends only on `base` and `bytestring`. I've added a dummy executable, and when compiled with `stack build --profile warp`, results in the following linker errors on Windows: {{{ Linking .stack-work\dist\e626a42b\build\linkerr\linkerr.exe ... C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0x920): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xc10): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xc70): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xdd8): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xe90): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xee0): more undefined references to `__chkstk_ms' follow collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) -- While building package warp-3.2.25 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build lib:warp exe:linkerr --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} This is preventing me from doing any profiling on my large program which is built on `warp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 05:59:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 05:59:23 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.3c591bcde3bab0a1075ec690ef2d4536@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "wai.zip" added. bug demo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 08:45:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 08:45:47 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.a8b7f576875e656c117546d6605f0c35@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Comment (by simonpj): As noted in my comment on the MR, I don't think this is Cabal's fault. I took a quick look but I can't see immediately why that is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 08:56:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 08:56:56 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.00fadf13d7760dd79ad27b9360d1765e@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:20 pkubaj]: > Running {{{make install}}} on powerpc64 throws error: > {{{ghc-cabal: '/usr/local/lib/ghc-8.6.3/bin/ghc-pkg' exited with an error: > array-0.5.3.0: Warning: haddock-interfaces: > /usr/local/share/doc/ghc-8.6.3/html/libraries/array-0.5.3.0/array.haddock > doesn't exist or isn't a file > array-0.5.3.0: dependency "base-4.12.0.0" doesn't exist (use --force to > override)}}} > > Still, {{{ghc}}} binary was installed, and it works. This is the bootstrap compiler that was cross compiled, isn't it? Does the compiler produced with the bootstrap compiler work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 08:58:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 08:58:58 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.8737d7e9ef095bf435482f4cd0ff603f@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:20 pkubaj]: > When i had {{{DYNAMIC_GHC_PROGRAMS=YES}}}, I used the script from > {{{bin/ghc}}}, but it threw the same error. It works with it disabled. > > When {{{DYNAMIC_GHC_PROGRAMS=YES}}}, {{{inplace/bin/ghc-stage2}}} is not present. {{{ghc-stage2}}} is in {{{ghc/stage2/build/tmp}}}: > {{{ > root at talos:$/home/pkubaj/ghc-8.6.3-boot$ find . -name ghc-stage2 > ./ghc/stage2/build/tmp/ghc-stage2 > }}} > > This binary seems to run ok. Does that compiler work to bootstrap GHC? > > > {{{ > root at talos:$/home/pkubaj/ghc-8.6.3-boot$ ./ghc/stage2/build/tmp/ghc- stage2 --version > The Glorious Glasgow Haskell Compilation System, version 8.6.3 > }}} Good, but does the compiler also produce working executables? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 09:32:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 09:32:07 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.bfde0206b5b85cb03f44551ad3d2bbcd@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:20 pkubaj]: > Also, when I bootstrap on amd64 and apply https://ghc.haskell.org/trac/ghc/attachment/ticket/15411/Disable-unboxed- arrays.patch, the following happens: > {{{ > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id base-4.12.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package- id ghc-prim-0.5.3 -package-id integer-simple-0.1.1.1 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O0 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated- flags -Wnoncanonical-monad-instances -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/Num.hs -o > libraries/base/dist-install/build/GHC/Num.o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.6.3 for powerpc64-portbld-freebsd): > Can't use Natural in base > }}} The error message says `powerpc64-portbld-freebsd` and it could also be #15411. On openSUSE I conditionally apply the patch (workaround) only on powerpc64, but just for fun I applied it on all platforms and build (in my home project) passes no problem. > > Without this patch, it compiles fine on amd64, but then fails on powerpc64. The latter is due to #15411. There is another patch that I apply to 8.6.3. That patch fixes an issue mentioned in my comments on #15399. You can find the patch in Phab:D5001. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 09:46:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 09:46:29 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.4b5821b23c2ea7945ff2f0d96f1542b5@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #15411 | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * status: closed => new * owner: trommler => (none) * resolution: fixed => * related: => #15411 Comment: The issue shown in the ticket is a duplicate of #15411. In the comments for this ticket we found the first breaking commit, which is unrelated to the issue on this ticket, and fixed (Phab:5001) one (out of 36) of the broken tests (see comment:5). I reopen the ticket so I won't forget to create a new ticket for the remaining 35 failing tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 09:47:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 09:47:11 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.b5d1bfa1072968075cca67b59c03e118@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #15411 | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I will submit a follow-up ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 09:56:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 09:56:02 -0000 Subject: [GHC] #16167: -ddump-json output empty with runghc Message-ID: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> #16167: -ddump-json output empty with runghc -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I create a haskell file called, for example, Main.hs which does not compile and run `ghc -ddump-json Main.hs` I will get a json formatted output after the error messages. This is a list of the errors, as expected. However if I run `runghc -ddump-json Main.hs` I get an empty list at the end `[]` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 10:06:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 10:06:04 -0000 Subject: [GHC] #16167: -ddump-json output empty with runghc In-Reply-To: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> References: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> Message-ID: <063.48a2a3b5860428664c8d3fa32c56700a@haskell.org> #16167: -ddump-json output empty with runghc -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Did you try with 8.6? Behaviour should be at least different due to fixing #14078. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 10:22:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 10:22:31 -0000 Subject: [GHC] #16168: Prelude docs for Integer mention J# Message-ID: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> #16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was just looking through http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Integer and noticed that it mentions `J#` and `I#`. This is certainly an implementation detail that should not be exposed to readers of the Prelude documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 11:07:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 11:07:51 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.2c27b23a59faab99ceea24bb15104d9a@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: 16140 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Comment (by RyanGlScott): comment:15 is a false alarm. See https://gitlab.haskell.org/ghc/ghc/merge_requests/112#note_2425. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 11:25:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 11:25:32 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.68f0c8946ef5e78f621547938c1d5e64@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've managed to hit that `foreignInterruptible` failure twice in the past week. Is it possible to push your commit from comment:5 to `master` so that this test is skipped? (Currently, that commit only exists on your branch, AFAICT.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 11:27:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 11:27:31 -0000 Subject: [GHC] #16167: -ddump-json output empty with runghc In-Reply-To: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> References: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> Message-ID: <063.34ef4aa77ebbd994e0f15a65184f2d40@haskell.org> #16167: -ddump-json output empty with runghc -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shmish111): Interesting, with 8.6.3 there is no output at all, also `-ddump-json -ddump-to-file` does not produce a file (I guess that makes sense based on the fact that `-ddump-json` seems to not do anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 11:33:00 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 11:33:00 -0000 Subject: [GHC] #16167: -ddump-json output empty with runghc In-Reply-To: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> References: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> Message-ID: <063.e000ae97de9c2b8c599635d3cd219b5e@haskell.org> #16167: -ddump-json output empty with runghc -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): With 8.6.2, {{{ > ghc f.hs -fforce-recomp -ddump-json {"span": null,"doc": "Loaded package environment from /root/sql- haskell/.ghc.environment.x86_64-linux-8.6.2","severity": "SevInfo","reason": null} {"span": {"file": "f.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 9},"doc": "parse error on input \u2018f\u2019","severity": "SevError","reason": null} }}} {{{ > runghc f.hs -fforce-recomp -ddump-json Loaded package environment from /root/sql- haskell/.ghc.environment.x86_64-linux-8.6.2 f.hs:1:8: error: parse error on input ‘f’ | 1 | module f | }}} I'm not sure why `runghc` behaves differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 11:59:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 11:59:39 -0000 Subject: [GHC] #16167: -ddump-json output empty with runghc In-Reply-To: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> References: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> Message-ID: <063.dd2ca648fe919add5047e999ba908f0a@haskell.org> #16167: -ddump-json output empty with runghc -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shmish111): Ok, I seem to have narrowed it down to the `-e ":set prog Main.hs"` flag ``` [nix-shell:~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.4 [nix-shell:~]$ ghc -x hs -e ":set prog Main.hs" -ddump-json Main2.hs Main2.hs:4:8: error: • Variable not in scope: undefinedx :: IO () • Perhaps you meant ‘undefined’ (imported from Prelude) | 4 | main = undefinedx | ^^^^^^^^^^ [] ``` ``` [nix-shell:~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 [nix-shell:~]$ ghc -x hs -e ":set prog Main.hs" -ddump-json Main2.hs Main2.hs:4:8: error: • Variable not in scope: undefinedx :: IO () • Perhaps you meant ‘undefined’ (imported from Prelude) | 4 | main = undefinedx | ^^^^^^^^^^ ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 12:03:26 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 12:03:26 -0000 Subject: [GHC] #16169: Unused variable warning affects compositionality when generating code Message-ID: <049.c91a69638b8e836837325d8e62669c29@haskell.org> #16169: Unused variable warning affects compositionality when generating code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I'm generating a program using template haskell, I might define a combinator to help me generate lambdas. {{{ type Code a = Q (TExp a) _lam :: (Code a -> Code b) -> Code (a -> b) _lam f = [|| \a -> $$(f [|| a ||]) ||] }}} However, if I now pass a constant function into `_lam`, the generated code contains an unused variable `a` that I can do nothing about and desire not to do anything about. {{{ c5 :: Code (a -> Int) c5 = _lam (const [|| 5 ||]) }}} However, GHC decides that it's wise to warn me about this when I splice it in. {{{ > $$c5 F2.hs:6:5: warning: [-Wunused-matches] Defined but not used: ‘a’ | 6 | q = $$c5 | ^^^ }}} As Ryan will tell you, I'm against emitting warnings from generated code as it breaks the abstraction. The code that is generated is guaranteed to be type and scope correct but any aesthetic warning is irrelevant to the consumer. I see it in precisely the same way as warning if we use a function that contains an unused variable in a library. Once the definition is exported from the library, its definition is opaque. The same principle should be applied to code generated by template haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 12:04:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 12:04:57 -0000 Subject: [GHC] #16167: -ddump-json doesn't work with -e (was: -ddump-json output empty with runghc) In-Reply-To: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> References: <048.8fe9f04627a74a309ae40d20cd7d5533@haskell.org> Message-ID: <063.d6be1d258987464776338f6ca191636b@haskell.org> #16167: -ddump-json doesn't work with -e -------------------------------------+------------------------------------- Reporter: shmish111 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer * version: 8.4.3 => 8.6.3 * os: MacOS X => Unknown/Multiple Comment: Ok, so it seems that `-ddump-json` doesn't work with `-e`. Shouldn't be too hard to fix if someone feels inclined. Thanks for narrowing it down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 12:35:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 12:35:04 -0000 Subject: [GHC] #16169: Unused variable warning affects compositionality when generating code In-Reply-To: <049.c91a69638b8e836837325d8e62669c29@haskell.org> References: <049.c91a69638b8e836837325d8e62669c29@haskell.org> Message-ID: <064.05ccd79e9092c93693b968b77d39a849@haskell.org> #16169: Unused variable warning affects compositionality when generating code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be easy to suppress all warnings in generated code. We already suppress some. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 13:57:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 13:57:58 -0000 Subject: [GHC] #15471: Polymorphism, typed splices and type inference don't mix In-Reply-To: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> References: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> Message-ID: <064.be76b90e8a375fb6162b9152f88b53d1@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5286, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/106 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T15471 * status: new => closed * differential: Phab:D5286 => Phab:D5286, https://gitlab.haskell.org/ghc/ghc/merge_requests/106 * resolution: => fixed * milestone: 8.10.1 => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/c2455e647501c5a382861196b64df3dd05b620a2 c2455e647501c5a382861196b64df3dd05b620a2]: {{{ commit c2455e647501c5a382861196b64df3dd05b620a2 Author: Matthew Pickering Date: Wed Jan 9 14:52:30 2019 +0000 Run typed splices in the zonker Summary: This fixes #15471 In the typechecker we check that the splice has the right type but we crucially don't zonk the generated expression. This is because we might end up unifying type variables from outer scopes later on. Reviewers: simonpj, goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15471 Differential Revision: https://phabricator.haskell.org/D5286 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 14:11:14 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 14:11:14 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.a3e54dedf26edfe1c797f4a5a4436319@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): OK, it turns out that `paraffins` regresses by 8% in counted instructions when allowing arbitrary closure growth because of the very same function I pinned down as the reason for the alleged speed-up in comment:56. It seems like we don't want to lift the inner loop of such a list comprehension. On the other hand, there's `gen_regexp` which improves by 2-5% in runtime when we lift the next-to-inner function of a list comprehension (`go_s7zy` below): {{{ let { go_s7zy = sat-only \r [x1_s7zz] case ># [x1_s7zz y_s7zx] of { __DEFAULT -> case chr# [x1_s7zz] of ds13_s7zB { __DEFAULT -> let { ds14_s7zC = CCCS C#! [ds13_s7zB]; } in let { z_s7zD = \u [] case +# [x1_s7zz 1#] of sat_s7zE { __DEFAULT -> go_s7zy sat_s7zE; }; } in let { go1_s7zF = sat-only \r [ds15_s7zG] case ds15_s7zG of { [] -> z_s7zD; : y1_s7zI ys_s7zJ -> let { sat_s7zL = \u [] go1_s7zF ys_s7zJ; } in let { sat_s7zK = CCCS :! [ds14_s7zC y1_s7zI]; } in : [sat_s7zK sat_s7zL]; }; } in go1_s7zF lvl13_s7zw; }; 1# -> [] []; }; } in case ord# [c1_s7za] of sat_s7zM { __DEFAULT -> go_s7zy sat_s7zM; }; }}} Lifting `go_s7zy` leads to a very slight increase in allocation (so would be disallowed from the perspective of closure growth), but a decrease in runtime. Maybe this is some low-level thing again, I don't know. The difference in Cmm is as expected and I wouldn't have expected a speed-up. So, to sum this up: Deactivating closure growth checks, thus allowing arbitrary closure growth resulting from lambda lifting - leads to an improvement of ~0.1% in runtime and counted instructions (though the two don't necessarily coincide). - also leads to unpredictable regressions in total allocations, like +28.6% in `wheel-sieve1`. From the regressions I investigated (`gen_regexp`, for example), the bindings the lifting decisions of which are responsible for the biggest regression in allocations (+10% due to the inner loop above, `go1_s7zF`) are not necessarily the same bindings which contribute the speed-ups (`go_s7zy` above). I'm not sure how to come up with a criterion that separates the two classes (beneficial to lift vs. not) of bindings, so I suggest we stick to the current closure growth heuristic. Which is a little more conservative than necessary, but avoids arbitrary regressions in allocations on STG level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 14:15:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 14:15:04 -0000 Subject: [GHC] #16169: Unused variable warning affects compositionality when generating code In-Reply-To: <049.c91a69638b8e836837325d8e62669c29@haskell.org> References: <049.c91a69638b8e836837325d8e62669c29@haskell.org> Message-ID: <064.e26f6d92b3e61cb360b751cc633af453@haskell.org> #16169: Unused variable warning affects compositionality when generating code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 14:15:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 14:15:15 -0000 Subject: [GHC] #15471: Polymorphism, typed splices and type inference don't mix In-Reply-To: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> References: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> Message-ID: <064.f7abe7f0c603e47a73152238aebbe83e@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5286, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/106 -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 15:07:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 15:07:39 -0000 Subject: [GHC] #16169: Unused variable warning affects compositionality when generating code In-Reply-To: <049.c91a69638b8e836837325d8e62669c29@haskell.org> References: <049.c91a69638b8e836837325d8e62669c29@haskell.org> Message-ID: <064.9ff2d2011cd6578188f93943118ec7c4@haskell.org> #16169: Unused variable warning affects compositionality when generating code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): There's an unfortunate tension here, since other folks have requested //more// warnings from generated code (in #14838). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 15:14:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 15:14:23 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.29d32fd26baeb364107028a1f791df2a@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: T14838 Blocked By: | Blocking: Related Tickets: #16169 | Differential Rev(s): Phab:D4440 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #16169 Comment: No idea why the original patch was reverted here but I still think close as working as intended. You wouldn't want a warning if an imported library function had an incomplete pattern so why is code generated by splices any different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:30:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:30:23 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.c505844efb9b281120d3d9ca316fab0f@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: T14838 Blocked By: | Blocking: Related Tickets: #16169 | Differential Rev(s): Phab:D4440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of historical context, the original patch was in reverted in light of #14899, where it was discovered that the only reason that `singletons` compiles in a reasonable amount of time is because pattern- match coverage checking is disabled for generated code. Technically, the problem still exists if you were to write this code by hand, but we deemed `singletons` to be an important-enough reason not to keep the patch :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:36:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:36:12 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.013d830cb690f449e2b613e02959202a@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I don't know why, but I just can't reproduce this, I always go past the point of registering the stage 1 RTS. Apparently, Andrey hasn't run into this either since he reported that his Windows builds were working just fine except for the Shake `--lint` problems from #15971. What I did run into is a failure to copy `_build/stage1/lib/x86_64 -windows-ghc-8.7.[...]/rts-1.0/include` to `_build/bindist/ghc-8.7 .[...]-unknown-mingw32`, because the former doesn't exist. What does exist is `_build/stage1/x86_64-windows-ghc-8.7.[...]/rts-1.0/include`, that is, without the `lib` in the middle. This seems quite wrong. As a reference, on my usual Linux system, the rts include dir is located under `_build/stage1/lib/x86_64-linux-ghc-8.7.20190111/rts-1.0/include`. This is from the same GHC commit as the one with which I tried to build a bindist on Windows. Andrey, I am failing to see where in Hadrian we could be doing things differently on Windows and other systems. Do you have any idea of what's going on? This doesn't help solve the error that the Windows CI runs into though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:44:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:44:45 -0000 Subject: [GHC] #10949: Document typed Template Haskell In-Reply-To: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> References: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> Message-ID: <062.d43d93f3d1ea30b918d70d78d803efbb@haskell.org> #10949: Document typed Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: invalid | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:45:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:45:01 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.1aff4c11ff3adf05ddc75f524535b097@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:49:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:49:37 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.1564be4d5d5453ffdb1d8a9fc68bc5b2@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T11452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:49:46 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:49:46 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.702c9b756bf86de8108bb39626bd3e11@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1344 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:50:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:50:08 -0000 Subject: [GHC] #12103: Typed Template Haskell missing utilities provided by untyped variant In-Reply-To: <046.b18752b937f18b0d4fa594e84b29566e@haskell.org> References: <046.b18752b937f18b0d4fa594e84b29566e@haskell.org> Message-ID: <061.d87e0f0b7b16eb760e04c68b96189772@haskell.org> #12103: Typed Template Haskell missing utilities provided by untyped variant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: wontfix | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:50:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:50:27 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.fe5e9b24074d7b5486ffd0146d62324e@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:51:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:51:21 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.9406279c2b689947ec50403ec8f8f083@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:52:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:52:06 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.23f909981345716e8fa0ab364d790d5a@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15437 Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:52:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:52:43 -0000 Subject: [GHC] #15863: Splcing a type class method selects the wrong instance In-Reply-To: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> References: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> Message-ID: <064.cbe6241c46ce9b04cf06e220fbb3f626@haskell.org> #15863: Splcing a type class method selects the wrong instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:52:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:52:53 -0000 Subject: [GHC] #15865: Typed template haskell and implicit parameters lead to incorrect results In-Reply-To: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> References: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> Message-ID: <064.797b75fb5cce95b317eb0109d7da593b@haskell.org> #15865: Typed template haskell and implicit parameters lead to incorrect results -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:53:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:53:07 -0000 Subject: [GHC] #15835: Internal error when splicing value constructed using typed template haskell In-Reply-To: <049.9e9d696239ebb85d54fd0730367bda33@haskell.org> References: <049.9e9d696239ebb85d54fd0730367bda33@haskell.org> Message-ID: <064.5547dc12eea4913c196148a347d745eb@haskell.org> #15835: Internal error when splicing value constructed using typed template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:53:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:53:17 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable In-Reply-To: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> References: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> Message-ID: <064.758fb8694cd55cb211a0d4179005b38f@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypedTemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:57:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:57:32 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian In-Reply-To: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> References: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> Message-ID: <064.073565509a60bbb50209da8384f276ec@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Merged here: https://gitlab.haskell.org/ghc/ghc/commit/6486c6e49c53e75f37ed732b38c5be7ae64785e8/pipelines?ref=master -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:58:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:58:21 -0000 Subject: [GHC] #11610: Remove IEThingAll constructor from IE datatype In-Reply-To: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> References: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> Message-ID: <064.82b057a9e1827f5edc5ee4676d958528@haskell.org> #11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 16:59:00 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 16:59:00 -0000 Subject: [GHC] #12488: Explicit namespaces doesn't enforce namespaces In-Reply-To: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> References: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> Message-ID: <064.c40ebcec8a921ad9207607174c445c60@haskell.org> #12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: ruperthorlick => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 17:40:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 17:40:56 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.0f9f3471d978438033844730d26e4659@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "wai.zip" added. bug demo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 17:40:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 17:40:56 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "wai.zip" removed. bug demo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 17:52:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 17:52:30 -0000 Subject: [GHC] #16170: Regression for #15806: -hT not available when profiling Message-ID: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> #16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: 15806 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 9 months ago, I opened #15806, which was about documenting when -hT can be used. Ben created some patches to resolve this, but with GHC 8.6.3, I find the behavior is identical to 8.4.2, namely: * -hT is disallowed for executables built with profiling * the docs make no mention of this * when profiling is enabled, the list of options for heap profiling make no mention of -hT, making me question my sanity. Ben apparently fixed all of these, but perhaps it never got merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 17:52:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 17:52:56 -0000 Subject: [GHC] #16170: Regression for #15806: -hT not available when profiling In-Reply-To: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> References: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> Message-ID: <062.fe4762b9e66ff9400a6acebf5044e92d@haskell.org> #16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15806 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * related: 15806 => #15806 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 17:59:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 17:59:45 -0000 Subject: [GHC] #16170: Regression for #15806: -hT not available when profiling In-Reply-To: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> References: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> Message-ID: <062.74f48f86a99e88429758743bf3ec3d7c@haskell.org> #16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15806 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Fixed by this MR I think: https://gitlab.haskell.org/ghc/ghc/merge_requests/94 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 18:02:16 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 18:02:16 -0000 Subject: [GHC] #16170: Regression for #15806: -hT not available when profiling In-Reply-To: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> References: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> Message-ID: <062.354d56c1aa3167bc5e1d23e6f81813f9@haskell.org> #16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15806 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 18:12:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 18:12:54 -0000 Subject: [GHC] #16170: Regression for #15806: -hT not available when profiling In-Reply-To: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> References: <047.ad4510d9ece73e8507f0d794011b1c40@haskell.org> Message-ID: <062.83109fbe88fb7624b5dce63642464bfe@haskell.org> #16170: Regression for #15806: -hT not available when profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: profiling Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15806 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => fixed Comment: Okay, looks like some coincidental timing. Closing as fixed by https://gitlab.haskell.org/ghc/ghc/merge_requests/94. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 19:41:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 19:41:47 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.011c46e2ce1d9d9dd7282fe1c9fa94fd@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Replying to [comment:21 trommler]: > Replying to [comment:20 pkubaj]: > > Running {{{make install}}} on powerpc64 throws error: > > {{{ > > ghc-cabal: '/usr/local/lib/ghc-8.6.3/bin/ghc-pkg' exited with an error: > > array-0.5.3.0: Warning: haddock-interfaces: > > /usr/local/share/doc/ghc-8.6.3/html/libraries/array-0.5.3.0/array.haddock > > doesn't exist or isn't a file > > array-0.5.3.0: dependency "base-4.12.0.0" doesn't exist (use --force to > > override) > >}}} > > > > Still, {{{ghc}}} binary was installed, and it works. > This is the bootstrap compiler that was cross compiled, isn't it? > > Does the compiler produced with the bootstrap compiler work? Not really. {{{ gmake install }}} didn't finish because of an error. {{{ghc}}} is there, but not all libraries are. {{{ root at talos:$~$ ghc --interactive GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help :1:6: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. :1:30: error: Not in scope: `System.IO.stdin' No module named `System.IO' is imported. :1:46: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. :1:70: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. :1:94: error: Not in scope: `System.IO.stdout' No module named `System.IO' is imported. :1:111: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. :1:135: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. :1:159: error: Not in scope: `System.IO.stderr' No module named `System.IO' is imported. :1:176: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 19:43:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 19:43:29 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.56f475cf1cd47da46ac27e326448c413@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Replying to [comment:22 trommler]: > Replying to [comment:20 pkubaj]: > > When i had {{{DYNAMIC_GHC_PROGRAMS=YES}}}, I used the script from > > {{{bin/ghc}}}, but it threw the same error. It works with it disabled. > > > > When {{{DYNAMIC_GHC_PROGRAMS=YES}}}, {{{inplace/bin/ghc-stage2}}} is not present. {{{ghc-stage2}}} is in {{{ghc/stage2/build/tmp}}}: > > {{{ > > root at talos:$/home/pkubaj/ghc-8.6.3-boot$ find . -name ghc-stage2 > > ./ghc/stage2/build/tmp/ghc-stage2 > > }}} > > > > This binary seems to run ok. > Does that compiler work to bootstrap GHC? > > > > > > {{{ > > root at talos:$/home/pkubaj/ghc-8.6.3-boot$ ./ghc/stage2/build/tmp/ghc- stage2 --version > > The Glorious Glasgow Haskell Compilation System, version 8.6.3 > > }}} > Good, but does the compiler also produce working executables? No, I couldn't bootstrap natively because of failed {{{gmake install}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 19:44:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 19:44:10 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.a573abdca41dddc61de4a05f66b16ea5@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Replying to [comment:23 trommler]: > Replying to [comment:20 pkubaj]: > > Also, when I bootstrap on amd64 and apply https://ghc.haskell.org/trac/ghc/attachment/ticket/15411/Disable-unboxed- arrays.patch, the following happens: > > {{{ > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id base-4.12.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package- id ghc-prim-0.5.3 -package-id integer-simple-0.1.1.1 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O0 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated- flags -Wnoncanonical-monad-instances -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/Num.hs -o > > libraries/base/dist-install/build/GHC/Num.o > > ghc-stage1: panic! (the 'impossible' happened) > > (GHC version 8.6.3 for powerpc64-portbld-freebsd): > > Can't use Natural in base > > }}} > The error message says `powerpc64-portbld-freebsd` and it could also be an instance of #15411. > > On openSUSE I conditionally apply the patch (workaround) only on powerpc64, but just for fun I applied it on all platforms and build (in my home project) passes no problem. > > > > Without this patch, it compiles fine on amd64, but then fails on powerpc64. > The latter is due to #15411. > > There is another patch that I apply to 8.6.3. That patch fixes an issue mentioned in my comments on #15399. You can find the patch in Phab:D5001. I can see that the patch at Phab:D5001 is already in 8.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 21:13:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 21:13:11 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable In-Reply-To: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> References: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> Message-ID: <064.e53e569b7a6ddd7bfb44837e4c75b6b4@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 21:13:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 21:13:33 -0000 Subject: [GHC] #15865: Typed template haskell and implicit parameters lead to incorrect results In-Reply-To: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> References: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> Message-ID: <064.4abd13a097e0692b13bbb4024f696aed@haskell.org> #15865: Typed template haskell and implicit parameters lead to incorrect results -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 21:13:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 21:13:56 -0000 Subject: [GHC] #15863: Splcing a type class method selects the wrong instance In-Reply-To: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> References: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> Message-ID: <064.5e7f7528bb4eb26c54618f80894761e9@haskell.org> #15863: Splcing a type class method selects the wrong instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 21:14:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 21:14:44 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.86277a4a3f6955a09579d52345bc64f6@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler (Type checker) => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 11 22:07:48 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Jan 2019 22:07:48 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.70afdc4f3e3d7ee3e1222f0f8230c1f6@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:26 pkubaj]: > Replying to [comment:23 trommler]: > > There is another patch that I apply to 8.6.3. That patch fixes an issue mentioned in my comments on #15399. You can find the patch in Phab:D5001. > > I can see that the patch at Phab:D5001 is already in 8.6.3. My bad. The additional patch is in Phab:D5212. There is no ticket for that patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 01:39:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 01:39:09 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.0f07a55316cad05f4f6aec651d2fe1b8@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Alp: I can reproduce this on my machine. Indeed, in addition to the directory `_build/stage0/lib`, I appear to also have `_build/stage0/x86_64 -windows-ghc-8.4.3`. If I look at a file like `_build/stage0/libraries/ghc-boot- th/build/autogen/Paths_ghc_boot_th.hs`, I can see the following directory settings: {{{ bindir = "${pkgroot}/..\\bin" libdir = "${pkgroot}/..\\x86_64-windows-ghc-8.4.3\\ghc-boot-th-8.7" dynlibdir = "${pkgroot}/..\\x86_64-windows-ghc-8.4.3" datadir = "${pkgroot}/..\\x86_64-windows-ghc-8.4.3\\ghc-boot-th-8.7" libexecdir = "${pkgroot}/..\\ghc-boot-th-8.7\\x86_64-windows-ghc-8.4.3 \\ghc-boot-th-8.7" sysconfdir = "${pkgroot}/..\\etc" }}} So, it looks like these settings are computed incorrectly. Is this done by Cabal? Or `ghc-pkg`? This is the Hadrian corner which I understand very little about. Could you show the above list of settings on your machine? Perhaps, Moritz could help figure this out, since I believe he was writing some of the associated code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 01:40:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 01:40:16 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.2ca266058793b6fbeaf965e6507c9ad7@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 02:22:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 02:22:32 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.b45bc8c5fed18c19b12f4f4932ffae77@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): This does look like Cabal. Do we know which commit introduced the breaking change? I think Cabal was bumped on master recently. But this could be a wrong lead. I guess some bisect would help pink this down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 04:04:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 04:04:17 -0000 Subject: [GHC] #16171: "ApplicativeDo" disables -Wunused-do-binds? Message-ID: <047.e4cd952a16923aafb66ec0a0f2c35588@haskell.org> #16171: "ApplicativeDo" disables -Wunused-do-binds? -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the code below, the return value of {{{forkIO}}} is ignored. The compiler fails to not warn about this. When I disable the {{{ApplicativeDo}}} extension, the warning appears as expected. {{{ {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ApplicativeDo #-} module Example (main) where import Control.Concurrent main :: IO () main = do x <- return () forkIO (putStrLn "hello") putStrLn $ "world" ++ show x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 04:09:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 04:09:39 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.ec856034fc06481971e8fcace2e57ef6@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 16147 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * status: new => patch * related: => 16147 Comment: This is in probably fixed with http://gitlab.haskell.org/ghc/ghc/merge_requests/95 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 05:08:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 05:08:09 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.3d2bcb76e96d6b2df9cf6cbf13636770@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks Moritz! I am not sure the bindist rule ever worked on Windows, because I don't recall testing it myself, and we never had it on CI. The default build target seems to be OK with incorrect directory settings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 09:50:48 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 09:50:48 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNjE2MzogRG9u4oCZdCB0aHJvdyBhbiBlcnJv?= =?utf-8?q?r_=28by_default=29_for_use_of_DEPRECATED_symbols_under?= =?utf-8?q?_-Werror?= In-Reply-To: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> References: <047.7725927825a16d3ceed7e138cdff894c@haskell.org> Message-ID: <062.7d4f2807fe3cd3e3f7e44e56b992bc8e@haskell.org> #16163: Don’t throw an error (by default) for use of DEPRECATED symbols under -Werror -------------------------------------+------------------------------------- Reporter: m-renaud | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Orthogonal to the `-Werror`-aspect, I strongly support cleaning up the currently conflated `-Wwarnings-deprecations`==`-Wdeprecations` situation. Currently there is no way to suppress `DEPRECATED`-warnings while being informed about `WARNING` pragmas (or vice-versa), nor the ability to promote/demote those individually to/from `-Werror`-severity. To restate it explicitly, my preference would be to end up with the following new situation: - `-Wdeprecations` ''(modified semantics)'' - warn if a module, function, or type marked `DEPRECATED` is imported or used. - `-Wwarnings` ''(new flag)'' - warn if a module, function, or type marked with `WARNING` is imported or used. - `-Wwarnings-deprecations` ''(unchanged semantics)'' - compat/legacy alias for the union `-Wwarnings -Wdeprecations` While retaining the logic as stated in the user's guide: > Warnings and deprecations are not reported for (a) uses within the defining module, (b) defining a method in a class instance, and (c) uses in an export list. The latter reduces spurious complaints within a library in which one module gathers together and re-exports the exports of several others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 12:35:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 12:35:23 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.3984eca2da79a49a6bcaa1d6a357fba2@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by osa1): Now that MR:103 is merged things are pretty good. Currently I can only make this test fail with `-DS` in non-threaded runtime, and that's because of the new sanity check I added with 82d1a88dec216d761b17252ede760da5c566007f. Hopefully this should be easier to fix as assertions failures are usually easy to figure out. The commit merged with MR:103: 74cd4ec5d2f9321aad5db3285cb60d78f2562996 Note that the commit in comment:3 was later reverted because it broke things. I'll try that commit again as it may have just revealed some of the bugs we fixed in the meantime. In the meantime if it was merged to 8.8 branch we should also merge the revert commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 12:44:44 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 12:44:44 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.68a1f5aa539c45b4dd84ab6b1256ae61@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by osa1): Ah, that's a bug in the sanity check. It turns out we don't update free pointers of arena blocks, instead we have a cached value of the free pointer and update that. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 13:12:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 13:12:38 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.07ea1b89e7c48036d69e83cfef10e031@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by osa1): Submitted MR:118 for this. Now only panic I can reproduce is Sanity.c:210 (the PAP invariant bug). I'll try enabling the commit in comment:3 again and see if it works after fixing all those other bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 14:23:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 14:23:53 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.335ae9b23ccafb9a2dfb0ed3557dd80c@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by osa1): The commit in comment:3 still causes problems. I think the problem is somewhere in `stg_ap_0_fast` in the profiling runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 14:45:11 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 14:45:11 -0000 Subject: [GHC] #16171: "ApplicativeDo" disables -Wunused-do-binds? In-Reply-To: <047.e4cd952a16923aafb66ec0a0f2c35588@haskell.org> References: <047.e4cd952a16923aafb66ec0a0f2c35588@haskell.org> Message-ID: <062.001738eec7d4d7be84d69744ff28e746@haskell.org> #16171: "ApplicativeDo" disables -Wunused-do-binds? -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by eschnett: Old description: > In the code below, the return value of {{{forkIO}}} is ignored. The > compiler fails to not warn about this. When I disable the > {{{ApplicativeDo}}} extension, the warning appears as expected. > > {{{ > {-# OPTIONS_GHC -Wall #-} > {-# LANGUAGE ApplicativeDo #-} > > module Example (main) where > > import Control.Concurrent > > main :: IO () > main = do x <- return () > forkIO (putStrLn "hello") > putStrLn $ "world" ++ show x > }}} New description: In the code below, the return value of {{{forkIO}}} is ignored. The compiler does not warn about this. When I disable the {{{ApplicativeDo}}} extension, the warning appears as expected. {{{ {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ApplicativeDo #-} module Example (main) where import Control.Concurrent main :: IO () main = do x <- return () forkIO (putStrLn "hello") putStrLn $ "world" ++ show x }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 16:27:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 16:27:22 -0000 Subject: [GHC] #16171: "ApplicativeDo" disables -Wunused-do-binds? In-Reply-To: <047.e4cd952a16923aafb66ec0a0f2c35588@haskell.org> References: <047.e4cd952a16923aafb66ec0a0f2c35588@haskell.org> Message-ID: <062.0eedf188d31ff2ff7d98b178b0bd89fe@haskell.org> #16171: "ApplicativeDo" disables -Wunused-do-binds? -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 18:01:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 18:01:55 -0000 Subject: [GHC] #16172: GHC 8.4 build failure on ARM Message-ID: <045.32113e8bbbf5196d56d38ab436e1f150@haskell.org> #16172: GHC 8.4 build failure on ARM --------------------------------+---------------------------------------- Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Using the same environment I used to build 8.6 and got the following error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4.20181014 for arm-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/HeapStackCheck.o' failed make[1]: *** [rts/dist/build/HeapStackCheck.o] Error 1 make[1]: *** Waiting for unfinished jobs.... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 12 22:34:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Jan 2019 22:34:52 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.0e3b521697cc7e0898f75371c8c2d5d4@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Replying to [comment:27 trommler]: > Replying to [comment:26 pkubaj]: > > Replying to [comment:23 trommler]: > > > There is another patch that I apply to 8.6.3. That patch fixes an issue mentioned in my comments on #15399. You can find the patch in Phab:D5001. > > > > I can see that the patch at Phab:D5001 is already in 8.6.3. > My bad. The additional patch is in Phab:D5212. There is no ticket for that patch. With this patch, I have the same result. I can bootstrap on amd64 just fine, but when compiling natively on powerpc64, I get: {{{ echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"8.6.3\"" >> utils/ghc-pkg/dist/build/Version.hs echo "targetOS = \"freebsd\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"powerpc64\"" >> utils/ghc- pkg/dist/build/Version.hs "/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.3-boot/bin/ghc-8.6.3" -H32m -O -I/usr/include -L/usr/lib -I/usr/local/include -L/usr/local/lib -Wall \ -optc-O2 -optc-pipe -optc-Wall -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp /ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,4,0,1 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec/src \ \ : cannot satisfy -package ghc-prim (use -v for more information) utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 00:41:30 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 00:41:30 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.532d1a81509dd7bd940845ae3920fdaf@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16141 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T16141 * status: patch => closed * resolution: => fixed Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/076f5862a9e46eef762ba19fb7b14e75fa03c2c0 076f5862a9e46eef762ba19fb7b14e75fa03c2c0]: {{{ commit 076f5862a9e46eef762ba19fb7b14e75fa03c2c0 Author: Ryan Scott Date: Sat Jan 12 19:05:46 2019 -0500 Don't invoke dataConSrcToImplBang on newtypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:26:37 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:26:37 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.93aa62d1fd8ca870a249225b5a87629d@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge Comment: Fixed with a34ee6154. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:26:59 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:26:59 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.db3c05b0df2d966f9f71fcb663e16e20@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:27:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:27:28 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.2606482d7291136af34d50866c3778f1@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The MR in comment:7 is merged as a34ee6154. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:28:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:28:01 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.fbca8a7f5380fb1a7f534f1942ef0c9b@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed Comment: Fixed with a34ee6154. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:28:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:28:16 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.47b818970f534d20b3946bbe2b044666@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed Comment: Fixed with a34ee6154. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:29:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:29:53 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.6e5a90039936890ec5fd77a5adf50e4a@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge * milestone: => 8.8.1 Comment: Fixed with 19670bc397. @bgamari I'm milestoning this to 8.8.1, please revert if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 05:40:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 05:40:21 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.300a194bc00a7443441de99d77e35f23@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Changes (by osa1): * status: new => merge Comment: Summary for 8.8.1: - If d13b7d6065 is merged, 8a6aa87766 (revert commit) should be merged too. - d90946cea1 and 74cd4ec5d2 should be merged. Updating the status to put this into the merge queue but we should revert this to "new" afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 07:52:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 07:52:14 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.276b553627069461829b0bb71150ab8e@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed Comment: Merges as 19670bc397d858b04eb9b4eb01480f7f8c59e2f5 (the commit fixes both this ticket and #15897). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 08:50:37 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 08:50:37 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.6ae4813a00e94ec3f9b7a9bcc16e91d3@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fumieval): That makes sense... Should I just disable the warning if such usecase is involved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 09:02:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 09:02:35 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.e623ee9924df8559fac3cf4cf813a707@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:28 pkubaj]: > With this patch, I have the same result. > > I can bootstrap on amd64 just fine, but when compiling natively on powerpc64, I get: > {{{ > echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs > echo "version = \"8.6.3\"" >> utils/ghc- pkg/dist/build/Version.hs > echo "targetOS = \"freebsd\"" >> utils/ghc- pkg/dist/build/Version.hs > echo "targetARCH = \"powerpc64\"" >> utils/ghc- pkg/dist/build/Version.hs > "/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.3-boot/bin/ghc-8.6.3" -H32m -O -I/usr/include -L/usr/lib -I/usr/local/include -L/usr/local/lib -Wall \ > -optc-O2 -optc-pipe -optc-Wall -optc-fno-stack-protector \ > }}} What are the steps to reproduce this? Without those it is really hard to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 09:35:59 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 09:35:59 -0000 Subject: [GHC] #16125: Broken Links in docs/users_guide/using-optimisation.rst In-Reply-To: <048.36371066852869c274db7532d64c9728@haskell.org> References: <048.36371066852869c274db7532d64c9728@haskell.org> Message-ID: <063.74c5e2e34f097c5518c4ca29fbd2ca70@haskell.org> #16125: Broken Links in docs/users_guide/using-optimisation.rst -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1574 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: patch => closed * resolution: => fixed Comment: Was merged to master by @ggreif (on GitLab). Thanks for reviewing and merging! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 09:40:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 09:40:51 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.b3c3d6e760e6d1e3ebb82967112d155f@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Data.Fixed, | Show, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: patch => closed * resolution: => fixed Comment: Was merged to master (https://gitlab.haskell.org/ghc/ghc/merge_requests/82). Thanks to @ggreif and @bgamari! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 11:42:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 11:42:29 -0000 Subject: [GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base` Message-ID: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> #16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple profunctor, QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14767 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Contravariant` was added in GHC 8.6. * https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Functor- Contravariant.html `Profunctor` also looks like fundamental abstraction to be worth considering adding to `base`. Having both `Profunctor` and `Choice` typeclasses in the `base` library will also allow to write `microprism` package similar to `microlens`. Prisms often turns to be very useful since they allow to work nicely with sum types. {{{#!hs type Prism s t a b = forall p f. (Choice p, Applicative f) => p a (f b) -> p s (f t) }}} Additional context for this ticket from Reddit: * https://www.reddit.com/r/haskell/comments/8v53cb/announce_ghc_861alpha1_available/e1o1giy/ It was proposed on Reddit to use `QuantifiedConstraints` for `Profunctor`. I'm not quite fluent with `QuantifiedConstraints`, but I think this may looks like this (mostly copy-pasting code from `profunctors` package): {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} class (forall a . Functor (p a)) => Profunctor p where {-# MINIMAL dimap | (lmap, rmap) #-} dimap :: (a -> b) -> (c -> d) -> p b c -> p a d dimap f g = lmap f . rmap g lmap :: (a -> b) -> p b c -> p a c lmap f = dimap f id rmap :: (b -> c) -> p a b -> p a c rmap = dimap id instance Profunctor (->) where dimap ab cd bc = cd . bc . ab lmap = flip (.) rmap = (.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 11:56:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 11:56:20 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.3687a12ea722db7bf5b4be005c85b47d@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): OK. You need FreeBSD sources in {{{/usr/src}}} and the current ports tree in {{{/usr/ports}}} (all on amd64). {{{ cd /usr/src pkg install devel/powerpc64-xtoolchain-gcc make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc TARGET_ARCH=powerpc64 buildworld make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc TARGET_ARCH=powerpc64 installworld DESTDIR=/sysroots/powerpc64 make CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc TARGET_ARCH=powerpc64 distribution DESTDIR=/sysroots/powerpc64 }}} Now you need wrappers for toolchain. I put mine to ~/bin: powerpc64-portbld-freebsd-ar: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-ar "$@" powerpc64-portbld-freebsd-g++: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-g++ --sysroot=/sysroots/powerpc64 "$@" powerpc64-portbld-freebsd-gcc: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=/sysroots/powerpc64 "$@" powerpc64-portbld-freebsd-ld: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-ld --sysroot=/sysroots/powerpc64 "$@" powerpc64-portbld-freebsd-nm: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-nm "$@" powerpc64-portbld-freebsd-objdump: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-objdump "$@" powerpc64-portbld-freebsd-ranlib: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-ranlib "$@" powerpc64-portbld-freebsd-strip: #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-strip "$@" {{{ cd /usr/ports/lang/ghc }}} Put your patches to {{{files}}}. {{{ make patch cd work/ghc-8.6.3 cp mk/build.mk.sample mk/build.mk }}} Add to mk/build.mk: {{{ INTEGER_LIBRARY = integer-simple BIN_DIST_NAME=ghc-8.6.3-boot BIN_DIST_TAR=ghc-8.6.3-boot.tar DYNAMIC_GHC_PROGRAMS = NO }}} Then it doesn't build with dtrace): {{{ ./configure --target=powerpc64-portbld-freebsd --disable-dtrace gmake gmake binary-dist TAR_COMP=xz mv ghc-8.6.3-boot-powerpc64-portbld-freebsd.tar.xz ghc-8.6.3-boot- powerpc64-freebsd.tar.xz }}} And copy ghc-8.6.3-boot-powerpc64-freebsd.tar.xz to my POWER box to {{{/usr/ports/distfiles}}}. On it, I have the same set of patches and a patch to {{{lang/ghc/bsd.ghc.mk}}}: {{{ Index: bsd.ghc.mk =================================================================== --- bsd.ghc.mk (revision 489844) +++ bsd.ghc.mk (working copy) @@ -5,12 +5,13 @@ # Maintained by: haskell at FreeBSD.org # -ONLY_FOR_ARCHS= aarch64 amd64 armv6 armv7 i386 +ONLY_FOR_ARCHS= aarch64 amd64 armv6 armv7 i386 powerpc64 DATADIR= ${PREFIX}/share/ghc-${GHC_VERSION} EXAMPLESDIR= ${PREFIX}/share/examples/ghc-${GHC_VERSION} -USES= autoreconf gmake iconv:translit localbase:ldflags ncurses perl5 tar:xz +USES= autoreconf compiler:c11 gmake iconv:translit localbase:ldflags \ + ncurses perl5 tar:xz USE_LOCALE= en_US.UTF-8 USE_PERL5= build NO_CCACHE= ccache: error: Failed to create directory /nonexistent/.ccache/tmp: Permission denied @@ -83,6 +84,8 @@ .if empty(PORT_OPTIONS:MBOOT) . if ${ARCH} == armv6 || ${ARCH} == armv7 BOOT_GHC_VERSION= 8.4.2 +.elif ${ARCH} == powerpc64 +BOOT_GHC_VERSION= 8.6.3 . else BOOT_GHC_VERSION= 8.4.3 . endif }}} You also need to add a proper SHA256 and SIZE entries to {{{lang/ghc/distinfo}}}: {{{ SHA256 (ghc-8.6.3-boot-powerpc64-freebsd.tar.xz) = 258f4d41d2cf7977f756e6a5ac718e5ed140065d31ba89c8aee4f654d57a6315 SIZE (ghc-8.6.3-boot-powerpc64-freebsd.tar.xz) = 179817644 }}} SHA256 is returned by {{{sha256}}} and SIZE is from {{{stat -f %z ghc-8.6.3-boot-powerpc64-freebsd.tar.xz}}}. Then: {{{ cd /usr/ports/lang/ghc make (I disable all options to avoid further problems) }}} Then just wait for an error. Alternatively, you could mark a BOOT option, and install ghc locally like this. {{{ cd /usr/ports/distfiles tar xvvf ghc-8.6.3-boot-powerpc64-freebsd.tar.xz cd ghc-8.6.3-boot CFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CXXFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CC=gcc8 CXX=g++8 ./configure gmake install }}} I hope it's clear enough :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 12:40:47 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 12:40:47 -0000 Subject: [GHC] #16174: GhcEnableTablesNextToCode=NO breaks NCG on macOS Message-ID: <047.938718f52639e6cdf277fbd52cb61d8c@haskell.org> #16174: GhcEnableTablesNextToCode=NO breaks NCG on macOS -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: NCG, TNCT, | Operating System: Unknown/Multiple TablesNextToCode | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears as if `GhcEnableTablesNextToCode=NO` breaks the NCG on macOS as early as GHC 8.4. Running the following {{{ git reset --hard HEAD git clean -xfd git submodule update --init --recursive git clean -xfd sed -E "s/^#BuildFlavour[ ]+= quick-cross$/BuildFlavour = quick/" < mk/build.mk.sample > mk/build.mk echo "GhcEnableTablesNextToCode=NO" >> mk/build.mk ./boot && ./configure --silent && make -s -j9 }}} on macOS with the 8.4 and 8.6 generated duplicate symbols in the assembly file. Something like {{{ .text .align 3 Lc4l: Lc4l: jmp Lc4u .const_data .align 3 .align 0 _Lc4l_info: .quad Lc4l .quad 259 .long 30 .long 0 }}} which causes the assembler to choke. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:05:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:05:18 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.8f8c5b14887570f19213261e70555cfb@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:30 pkubaj]: > Add to mk/build.mk: > {{{ > INTEGER_LIBRARY = integer-simple > BIN_DIST_NAME=ghc-8.6.3-boot > BIN_DIST_TAR=ghc-8.6.3-boot.tar > DYNAMIC_GHC_PROGRAMS = NO > }}} You want to add to `mk/build.mk`: {{{ Stage1Only = NO }}} Then you will find `inplace/bin/ghc-stage2` and that will be the compiler running on powerpc64. The file that is executed by `inplace/bin/ghc-stage1` runs on amd64 (the host machine) as you can see from the output of `file`: {{{ /ghc-8.6.2/inplace/lib> file bin/ghc-stage1 bin/ghc-stage1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=846ac234d6774bbd928e3da433fd4f75482c0609, with debug_info, not stripped }}} Note: I built the cross compiler on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:26:44 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:26:44 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.59f18d909c015b8727dedff9ff6c789d@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Data.Fixed, | Show, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:28:49 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:28:49 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.6887c8d3a7b87c89e1c81293a3382236@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T16096 Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/should_run/T16096 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:29:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:29:50 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.031ce142fb0be3b54c5f1ee00290043d@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.3 Resolution: fixed | Keywords: seq sprint | strictness Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | ghci/scripts/T16089 Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T16089 * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:30:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:30:51 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.6f96e47e911635db19b308eefc2d1667@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:32:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:32:22 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.9f2d0bddbae58b48a054731560a28730@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11606 Blocked By: | Blocking: Related Tickets: #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T11606 * milestone: 8.4.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 13:33:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 13:33:55 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.67b07f62fd77b40994553d62b04e05cf@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Data.Fixed, | Show, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/data-fixed- | show-read Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => libraries/base/tests/data-fixed-show-read -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 15:33:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 15:33:01 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.4f3a9bee58e0f424864c6c90584e8ac9@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): I added {{{Stage1Only = NO}}} {{{ root at oamd64:$/usr/ports/lang/ghc/work/ghc-8.6.3$ tail mk/build.mk HADDOCK_DOCS = NO #EXTRA_HADDOCK_OPTS += --quickjump --hyperlinked-source # Don't strip debug and other unneeded symbols from libraries and executables. STRIP_CMD = : INTEGER_LIBRARY = integer-simple BIN_DIST_NAME=ghc-8.6.3-boot BIN_DIST_TAR=ghc-8.6.3-boot.tar DYNAMIC_GHC_PROGRAMS = NO Stage1Only = NO }}} Then: {{{ gmake clean gmake -j 8 && gmake binary-dist TAR_COMP=xz }}} But after untaring it, ghc-stage2 is still in {{{ghc/stage2/build/tmp}}}. {{{ root at talos:$/home/pkubaj/ghc-8.6.3-boot$ find . -name ghc-stage2 ./ghc/stage2/build/tmp/ghc-stage2 }}} And it's a binary: {{{ root at talos:$/home/pkubaj/ghc-8.6.3-boot$ file ./ghc/stage2/build/tmp/ghc- stage2 ./ghc/stage2/build/tmp/ghc-stage2: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 12.0 (1200086), with debug_info, not stripped }}} I attempted to install it anyway with: {{{ CFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CXXFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CC=gcc8 CXX=g++8 ./configure gmake install }}} This threw the following error: {{{ ghc-cabal: '/usr/local/lib/ghc-8.6.3/bin/ghc-pkg' exited with an error: ghc-boot-th-8.6.3: Warning: haddock-interfaces: /usr/local/share/doc/ghc-8.6.3/html/libraries/ghc-boot-th-8.6.3/ghc-boot- th.haddock doesn't exist or isn't a file ghc-boot-th-8.6.3: dependency "base-4.12.0.0" doesn't exist (use --force to override) gmake[1]: *** [ghc.mk:991: install_packages] Error 1 gmake: *** [Makefile:51: install] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 16:29:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 16:29:34 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.10b4f35e287cf623137b2305f6eaf291@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Would a full build log from amd64 help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 17:44:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 17:44:34 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.c059c3c35bdcdcaa58ff2e267d9a3dd1@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:32 pkubaj]: > Then: > {{{ > gmake clean > gmake -j 8 && gmake binary-dist TAR_COMP=xz > }}} On amd64, what is the contents of `inplace/bin` after the above? On powerpc64, what is your PATH environment variable set to, when you install? You want `/usr/local/bin` before `/usr/bin` so during installation new binutils are used. Can you also add the output of `ldd /usr/local/lib/ghc-8.6.3/bin/ghc-pkg`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 17:45:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 17:45:32 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.78fd1704215188d5b654c6d95cb8a5d9@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:33 pkubaj]: > Would a full build log from amd64 help? Why don't you just attach it to the ticket and I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 18:29:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 18:29:25 -0000 Subject: [GHC] #16175: wrong wording (and possibly wrong location) in parse error message for "do $ bar" Message-ID: <049.32ced2f00d71c7dbfe8b0e4d9811590f@haskell.org> #16175: wrong wording (and possibly wrong location) in parse error message for "do $ bar" -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not a bug, as GHC correctly rejects an invalid program. Still - {{{ Prelude> foo x = do $ bar ; return () :1:20: error: Parse error: module header, import declaration or top-level declaration expected. }}} Of the three suggestions, only "top-level declaration" can actually happen here (as this also happens deep inside a module). For reference, * ghc-7.10 : "parse error on input ‘=’" * ghc-8.0 : "naked expression at top level" * ghc-8.2 and later: as above I think the wording was introduced with https://ghc.haskell.org/trac/ghc/ticket/12146 Anyway one could also think that the actual error happened earlier, since after removing "return ()" as suggested by the error message, we get {{{ Prelude> foo x = do $ bar :1:9: error: Empty 'do' block }}} so GHC could also use this as the original error message? By putting "; return ()" at the end, the 'do' block does not become non-empty? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 18:47:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 18:47:39 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.209f8d4c3101e869595c323f1f3126e7@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): I'm running build with one thread (so that it's clearer to look at, but it will take a while to build). My PATH is definitely wrong, though: {{{ /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 22:04:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 22:04:50 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.38d0b9316f353d333deddccc74d28004@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): {{{ root at openvas:$/usr/ports/lang/ghc/work/ghc-8.6.3/inplace/bin$ ls count_lines deriveConstants genapply genprimopcode ghc-cabal ghc-pkg ghc-stage1 ghc-stage2 hp2ps hpc hsc2hs mkdirhier runghc }}} {{{ root at openvas:$/usr/ports/lang/ghc/work/ghc-8.6.3$ tar tvvf ghc-8.6.3-boot- powerpc64-portbld-freebsd.tar.xz | grep inplace -rwxr-xr-x 0 root wheel 43 Jan 13 19:42 ghc-8.6.3-boot/inplace/bin/mkdirhier -rwxr-xr-x 0 root wheel 8864 Jan 13 20:15 ghc-8.6.3-boot/inplace/lib/bin/ghc-split }}} So it looks like {{{binary-dist}}} step is wrong. I'll soon upload a full log. ldd: {{{ /usr/local/lib/ghc-8.6.3/bin/ghc-pkg: libm.so.5 => /lib/libm.so.5 (0x811318000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x81135e000) libutil.so.9 => /lib/libutil.so.9 (0x8113e4000) librt.so.1 => /usr/lib/librt.so.1 (0x81140f000) libdl.so.1 => /usr/lib/libdl.so.1 (0x811427000) libthr.so.3 => /lib/libthr.so.3 (0x811439000) libc.so.7 => /lib/libc.so.7 (0x811483000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8117ea000) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 22:17:24 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 22:17:24 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.f6460f8a848bc63a95848958dad89a0e@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Changes (by pkubaj): * Attachment "ghc.log.xz" added. log file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 13 22:17:58 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Jan 2019 22:17:58 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.78dd8682cdabae9b8a3f45d4bfd2037e@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): Log has ./configure, gmake and gmake binary-dist steps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 04:42:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 04:42:56 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.816767efbf3961b1d24a834d225a4960@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: tmobile Type: bug | Status: closed Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chessai): * status: new => closed * resolution: => fixed Comment: fixed in https://github.com/haskell/hsc2hs/commit/fac8b62e48f4c99cfe8f3efff63c8fcd94b2a1d6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 08:44:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 08:44:35 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.5661d3950a4271dcbead527efa7a0ada@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > That makes sense... Should I just disable the warning if such usecase is involved? I suppose so. I don't know a better path at the moment -- the warning IS often useful, so I'm reluctant to get rid of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 09:27:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 09:27:28 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.6e3fff726dc5b7268b7dfb36b3812964@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:37 pkubaj]: > So it looks like {{{binary-dist}}} step is wrong. I'll soon upload a full log. No, it is fine. A binary dist is prepared so the files in it can be installed, and for that it doesn't need most of the `inplace` scripts. > > ldd (on powerpc64): > {{{ > /usr/local/lib/ghc-8.6.3/bin/ghc-pkg: > libm.so.5 => /lib/libm.so.5 (0x811318000) > libncursesw.so.8 => /lib/libncursesw.so.8 (0x81135e000) > libutil.so.9 => /lib/libutil.so.9 (0x8113e4000) > librt.so.1 => /usr/lib/librt.so.1 (0x81140f000) > libdl.so.1 => /usr/lib/libdl.so.1 (0x811427000) > libthr.so.3 => /lib/libthr.so.3 (0x811439000) > libc.so.7 => /lib/libc.so.7 (0x811483000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8117ea000) > }}} Here we are at something. `libgcc_s.so.1` is taken from `/lib` while it should be coming from `gcc8`. Did you set `CFLAGS` and`LDFLAGS` to also point gcc's directory on powerpc64 (with `-Wl,rpath=...`) when you were building on amd64? Could you also post the output of `readelf -d /usr/local/lib/ghc-8.6.3/bin /ghc-pkg` on powerpc64? I am only interested in lines that contain `RUNPATH` or `RPATH`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 10:56:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 10:56:32 -0000 Subject: [GHC] #16176: Let-insertion for template haskell Message-ID: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place. For example {{{ foo x = [|| $$x + $$x ||] }}} Will generate a program which completely duplicates its argument. In this case I can manually remove the duplicate by inserting a let. {{{ foo x = [|| let x' = $$x in x' + x' ||] }}} Not too bad but a bit annoying to have to do manually. When constructing bigger programs however this process becomes tedious or impossible to do correctly by hand. {{{ foo :: (Q (TExp (Bool)) -> Q (TExp Int)) -> Q (TExp Int) foo xf = [|| (let x = True in $$(xf [|| x ||])) + (let x = False in $$(xf [|| x ||]) ||] }}} Now if I pass a constant function to `foo`, the resulting code won't mention `x` so it could be floated out. However, there's not way I can tell that without running `xf` so I can't perform the same transformation as I did for the earlier program and manually insert a let. In the case of splicing in fully static data you really want it to float to the top-level and turn into a CAF. The proposal of this ticket is to implement something like the mechanism for let-insertion in metaocaml. http://okmij.org/ftp/meta-programming/#let-insert We add two new primitives: {{{ genlet :: Q (TExp a) -> Q (TExp a) let_locus :: Q (TExp a) -> Q (TExp a) }}} `genlet` marks a code value that we want to float. `let_locus` marks places where we want to insert a let. When we evaluate the code fragment and encounter a `genlet` call, whatever the argument evaluates to is floated as far upwards as possible and inserted at the position of one of the loci. For example, {{{ sqr :: Code Int -> Code Int sqr c = [|| $$c + $$c ||] sqr_let :: Code Int -> Code Int sqr_let c = let_locus (sqr (genlet c)) }}} Splicing `sqr [|| 1 ||]` will result in `1 + 1` but `sqr_let [|| c ||]` will equal `let x = 1 in x + x ||]`. It's important to do this earlier rather than later as a lot of duplication can take place which the simplifier does not like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:01:43 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:01:43 -0000 Subject: [GHC] #16177: Rename Q (TExp a) to Code a Message-ID: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> #16177: Rename Q (TExp a) to Code a -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I propose that we modify the typed template haskell API so that quoting an expression of type `t` results in a value of type `Code t` rather than `Q (TExp a)` and the splice construct requires an argument of type `Code a` to produce a value of type `a`. The definition of `Code` is as follows. {{{ newtype Code a = Code (Q (TExp a)) }}} There are two good reasons to do this. 1. `Q (TExp a)` is ugly and leaks implementation details to the user. Using effects from the `Q` monad is unsafe and against the principle of staged programming. 2. Writing instances for `Q (TExp a)` is quite difficult. It's much easier when the newtype is defined but at the cost of constant wrapping and unwrapping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:01:44 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:01:44 -0000 Subject: [GHC] #16176: Let-insertion for template haskell In-Reply-To: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> References: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> Message-ID: <064.62302d42b77282b628988ede55bb55c3@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Now if I pass a constant function to foo, the resulting code won't mention x so it could be floated out. Is this really a common case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:15:48 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:15:48 -0000 Subject: [GHC] #16178: Brackets and splices should be overloaded like the static keyword Message-ID: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> #16178: Brackets and splices should be overloaded like the static keyword -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's quite convenient that the `static` keyword is rebindable. To recap, if `e :: T` then `static e :: (IsStatic p) => p t`. It should also be possible rebind brackets and splices in the same manner. So we introduce two type classes `IsBracket` and `IsSplice`. Now quoting a term `e :: T` has type `e :: IsBracket p => p T` and the argument to a splice must have type `e :: IsSplice p => p T` which results in a value of type `T`. {{{ class IsBracket p where fromBracket :: Code t -> p t class IsSplice p where toBracket :: p t -> Code t foo :: IsBracket p => p Int foo = [|| 5 ||] qux :: (IsSplice p, IsBracket p) => Int qux = $$(foo) }}} As an aside, arguably the `static` form should only be rebindable when `RebindableSyntax` is enabled but that boat seems to have sailed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:17:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:17:46 -0000 Subject: [GHC] #16054: Unable to build stage3 with hadrian In-Reply-To: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> References: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> Message-ID: <064.d57ff523f8c00cf7cce7692b5e6a0b5c@haskell.org> #16054: Unable to build stage3 with hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5458 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Merged in https://gitlab.haskell.org/ghc/ghc/commit/6486c6e49c53e75f37ed732b38c5be7ae64785e8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:21:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:21:46 -0000 Subject: [GHC] #16176: Let-insertion for template haskell In-Reply-To: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> References: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> Message-ID: <064.40d9adca6bef393ead0fa53dba49faf0@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Perhaps it is not common but it can become increasingly cumbersome to manually insert lets as your program gets more complicated. Another example is if your program generates a small list statically in many different places you just want this to float outwards. Manually let binding it requires adding additional arguments which makes the program more difficult to understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 11:22:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 11:22:08 -0000 Subject: [GHC] #16178: Brackets and splices should be overloaded like the static keyword In-Reply-To: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> References: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> Message-ID: <064.e5fef45a04680a39410b918e7cf57fb3@haskell.org> #16178: Brackets and splices should be overloaded like the static keyword -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could you give some examples of how this new ability would be useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 12:25:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 12:25:46 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.3d6b43b4dc10fb36f6ddc5d8ac33e8a5@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by pkubaj): My wrappers for GCC have {{{--sysroot}}} option: {{{ root at openvas:$~$ cat /root/bin/powerpc64-portbld-freebsd-gcc #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=/sysroots/powerpc64 "$@" }}} {{{ root at openvas:$~$ cat /root/bin/powerpc64-portbld-freebsd-ld #!/bin/sh exec /usr/local/bin/powerpc64-unknown-freebsd12.0-ld --sysroot=/sysroots/powerpc64 "$@" }}} This should take care of {{{CFLAGS}}} and {{{LDFLAGS}}}. There are no {{{RUNPATH}}} or {{{RPATH}}} entries: {{{ root at talos:$~$ readelf -d /usr/local/lib/ghc-8.6.3/bin/ghc-pkg | awk '/RUNPATH/ || /RPATH/' root at talos:$~$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 13:43:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 13:43:46 -0000 Subject: [GHC] #16178: Brackets and splices should be overloaded like the static keyword In-Reply-To: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> References: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> Message-ID: <064.88cf6270727b2c78e5d61b94b94ebd11@haskell.org> #16178: Brackets and splices should be overloaded like the static keyword -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If you define a partially static monoid type such as the following which tries to evaluate as many concatenations statically as possible. {{{ data PS a = Static a | Dynamic (Code a) instance Monoid a => Monoid (PS a) where mempty = Static mempty (Static a) <> (Static b) = Static (a <> b) -- Using the overloading here a <> c = [|| $$a <> $$c ||] lower :: Lift a => PS a -> Code a lower (Static a) = lift a lower (Dynamic c) = c instance IsSplice PS where toBracket = lower instance IsBracket PS where fromBracket = Dynamic sta :: a -> PS a sta = Static }}} Writing programs with this data type becomes much more pleasant as the additional lifting and lowering become transparent. You can combine together these layers multiple times to implicitly perform different rewritings but the client's splice will still end up looking the same. {{{ prog = (sta () <> sta ()) <> [|| () ||] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 13:53:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 13:53:00 -0000 Subject: [GHC] #16176: Let-insertion for template haskell In-Reply-To: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> References: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> Message-ID: <064.82cfffbed12f6461136b26efef490671@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think a proposal such as this would benefit from more eyes. Would you consider a ghc-proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 13:54:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 13:54:50 -0000 Subject: [GHC] #16177: Rename Q (TExp a) to Code a In-Reply-To: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> References: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> Message-ID: <064.737564cec75003af28b70bb3235b871c@haskell.org> #16177: Rename Q (TExp a) to Code a -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This also (in reference to #16176) might be a ghc-proposal. What operations in the `Q` monad are unsafe? Surely not lookups. Perhaps you mean unsafe in the sense that they aren't reflected in typed TH? I'm really not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 14:31:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 14:31:11 -0000 Subject: [GHC] #16177: Rename Q (TExp a) to Code a In-Reply-To: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> References: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> Message-ID: <064.a19dfbf63230a7d01748e4a5823842c6@haskell.org> #16177: Rename Q (TExp a) to Code a -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Unsafe meaning that running a splice can fail in any manner. Under that definition there are a few unsafe operations `qAddTopDecls`, `qRunIO`, `qReport` come immediately to mind. The other `qReify*` operations should be discouraged as well as they go against how people should be writing their typed template haskell programs (in my opinion). Dispatching based of these I guess is possible in a safe manner but I'm not sure how you could do much usefully as you have to construct a `Name` in order to use them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 14:39:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 14:39:09 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.7a1d4bc9ca95e3dbe4911f0ecc8bb671@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: tmobile => (none) * status: closed => new * resolution: fixed => Comment: While this feature has been added to `hsc2hs`, I'd like to keep this ticket open since there are two remaining tasks to be done on GHC's side: * Update GHC's `hsc2hs` submodule to actually use this new `hsc2hs` feature. * Add some tests cases to GHC's testsuite which demonstrate that this feature actually works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 16:08:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 16:08:33 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.bd6f249f720615a2521bc6005c519c99@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): iceland_jack: Ryan thinks you use this feature a lot. Is that true? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 16:08:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 16:08:58 -0000 Subject: [GHC] #16176: Let-insertion for template haskell In-Reply-To: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> References: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> Message-ID: <064.b637addd3e66c692bf37f322e889f6ea@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): A note about the metaocaml implementation. That works by trying to insert the expression at each locus and choosing the most outermost scope where it is possible to insert the expression. This check is performed by attempting to run the splice and then catching an exception if it leads to a variable being out of scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 16:58:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 16:58:07 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled Message-ID: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When {{{DeriveAnyClass}}} and {{{GeneralizedNewtypeDeriving}}} are both enabled, GHC prints out the following warning for every {{{deriving C}}}: {{{ #!haskell warning: • Both DeriveAnyClass and GeneralizedNewtypeDeriving are enabled Defaulting to the DeriveAnyClass strategy for instantiating C }}} Would it be useful to point the users to {{{DerivingStrategies}}} ? {{{Use DerivingStrategies to pick a different strategy}}}, or something similar? I'm not sure if this was already discussed before, I couldn't find any related tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 17:03:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 17:03:51 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled In-Reply-To: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> References: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> Message-ID: <063.b08611a4ff05b03178c1f6d54e42308a@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15839 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 17:04:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 17:04:09 -0000 Subject: [GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag In-Reply-To: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> References: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> Message-ID: <059.13635879ad6c266c0c302ccc3994efe2@haskell.org> #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #16179 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #16179 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 17:48:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 17:48:14 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled In-Reply-To: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> References: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> Message-ID: <063.58e6075df39b321a2e649cf06697f21d@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15839 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That sounds like a reasonable thing to add to the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 17:55:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 17:55:46 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.e329b97797daeec148e65961bfebb0ae@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not Icelandic, but I can provide one "real-world" use case for this feature from the `singletons` library. It used to be the case that we had about eight or so data types of this shape: {{{#!hs data TyCon1 :: (k1 -> k2) -> (k1 ~> k2) data TyCon2 :: (k1 -> k2 -> k3) -> (k1 ~> k2 ~> k3) data TyCon3 :: (k1 -> k2 -> k3 -> k4) -> (k1 ~> k2 ~> k3 ~> k4) data TyCon4 :: (k1 -> k2 -> k3 -> k4 -> k5) -> (k1 ~> k2 ~> k3 ~> k4 ~> k5) data TyCon5 :: (k1 -> k2 -> k3 -> k4 -> k5 -> k6) -> (k1 ~> k2 ~> k3 ~> k4 ~> k5 ~> k6) data TyCon6 :: (k1 -> k2 -> k3 -> k4 -> k5 -> k6 -> k7) -> (k1 ~> k2 ~> k3 ~> k4 ~> k5 ~> k6 ~> k7) data TyCon7 :: (k1 -> k2 -> k3 -> k4 -> k5 -> k6 -> k7 -> k8) -> (k1 ~> k2 ~> k3 ~> k4 ~> k5 ~> k6 ~> k7 ~> k8) data TyCon8 :: (k1 -> k2 -> k3 -> k4 -> k5 -> k6 -> k7 -> k8 -> k9) -> (k1 ~> k2 ~> k3 ~> k4 ~> k5 ~> k6 ~> k7 ~> k8 ~> k9) }}} We arbitrarily capped off the maximum at eight. With the advent of polymorphic data family return kinds, however, we were able to consolidate all of this down into just three things: {{{#!hs data family TyCon :: (k1 -> k2) -> unmatchable_fun type family ApplyTyCon (f :: k1 -> k2) (x :: k1) :: k3 where ApplyTyCon (f :: k1 -> k2 -> k3) x = TyCon (f x) ApplyTyCon f x = f x type instance Apply (TyCon f) x = ApplyTyCon f x }}} Now we don't need to copy-paste `TyCon` multiple times, and better yet, we don't have to arbitrarily set a maximum of eight, since `ApplyTyCon` lets us go to whatever arity we desire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 18:52:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 18:52:41 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.c68809b901e6ba6cc7bcc3dca6517cfa@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:40 pkubaj]: > This should take care of {{{CFLAGS}}} and {{{LDFLAGS}}}. > > There are no {{{RUNPATH}}} or {{{RPATH}}} entries: > {{{ > root at talos:$~$ readelf -d /usr/local/lib/ghc-8.6.3/bin/ghc-pkg | awk '/RUNPATH/ || /RPATH/' > root at talos:$~$ > }}} This explains why ghc-pkg is picking up `libgcc_s.so.1` from `/lib`. You want to make sure `/usr/local/lib/gcc8/libgcc_s.so.1` shows up in `ldd ghc-pkg`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 18:54:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 18:54:06 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.e1e99462fe4f0775c6efc665deae2b37@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): See also https://github.com/haskell/haskell-ide-engine/issues/1053 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 19:38:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 19:38:40 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.7ea570ba38ce58a4c886e3fe0a004c77@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:38 pkubaj]: > Log has ./configure, gmake and gmake binary-dist steps. The cross compiler on amd64 is gcc 6.4 while on powerpc64 it is gcc 8. Could you make sure both versions agree? I want to get as many potential sources of trouble out of the equation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 19:42:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 19:42:46 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.bb8e219e455b61a4e5a0f2692926ab6f@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:32 pkubaj]: > I attempted to install it anyway with: > {{{ > CFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CXXFLAGS="-Wl,-rpath=/usr/local/lib/gcc8 -isystem /usr/local/include" CC=gcc8 CXX=g++8 ./configure > gmake install > }}} It is too late to specify `-Wl,-rpath=/usr/local/lib/gcc8` during install, you need to do it on amd64 during build-time. Installing a binary-dist does not re-link libraries like `libtool` AFAIK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 19:54:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 19:54:08 -0000 Subject: [GHC] #16177: Rename Q (TExp a) to Code a In-Reply-To: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> References: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> Message-ID: <064.66d500ef03a3edd8e60571f6fd34da06@haskell.org> #16177: Rename Q (TExp a) to Code a -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I still say this is best debated in a ghc-proposal. There are significant design/policy decisions here that will benefit from a broad audience. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:02:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:02:30 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled In-Reply-To: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> References: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> Message-ID: <063.6b8ce9eb9093a5fb7fe24794942fafe6@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15839 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/120 -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/120 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:09:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:09:50 -0000 Subject: [GHC] #16177: Rename Q (TExp a) to Code a In-Reply-To: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> References: <049.7595543e7f86f8b61096d4225f17a85f@haskell.org> Message-ID: <064.85ed6616265e8ed867da2ef84287af21@haskell.org> #16177: Rename Q (TExp a) to Code a -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I agree with you Richard. I'll get around to it along with #16176. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:17:44 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:17:44 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.3ab8584060360fbb598092889406ae81@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Some thoughts from this morning's call: * The error report in the original report is unrelated to this ticket: it's just #12088 again. Adding a TH splice does the trick, giving this minimal example: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds, TemplateHaskell #-} module Bug where import Data.Kind data family Fix (f :: Type -> k) :: k type family F a type instance F Int = Type -> Type $(return []) data instance Fix (f :: Type -> F Int) (x :: Type) = Mk }}} This is accepted, by transforming the instance to {{{#!hs data instance Fix @(Type -> Type) (f :: Type -> Type) (x :: Type) = Mk }}} In other words, GHC just realizes it can replace `F Int` with `Type -> Type` and carry on. * In an attempt to stop GHC from being this clever, we tried using visible dependent quantification: {{{#!hs data family Fix k (f :: Type -> k) :: k data instance Fix (F Int) (f :: Type -> F Int) (x :: Type) = Mk }}} Note that `k` is explicit now. This panics, because the `unravelFamInstPats` chokes on the strange instance, causing downstream chaos. (Really, `unravelFamInstPats` should panic.) However, if somehow the plumbing were fixed, this would be rejected because it mentions a type family in a type pattern. * In another attempt to defeat the ever-clever GHC, I tried using an explicit forall. {{{#!hs data family Fix (f :: Type -> k) :: k data instance forall (f :: Type -> F Int) (x :: Type). Fix f x = Mk }}} This works by instantiating `Fix` with `Type -> Type` (as before) and casting `f`. * Previously, Simon was worried about the fact that there might be a difference in behavior between eager unification and the work the solver does. But I don't think there is, as `solveEqualities` is called ''before'' `unravelFamInstPats`. * The problem here is really all about when type families get in the way of exposing arrows in the data family's kind. In the `Fix` example, the type family `F Int` obscures the underlying type `Type -> Type`. How do we specify when such a problem exists? * I conjecture that the problem never exists on its own. This obfuscation can happen only in two ways: (1) either some kind parameter has been instantiated with a type family application, or (2) a type family application appears in the return kind of a data family. In case (1), we're blocked by #12564; that case cannot happen. In case (2), we're blocked by #14645. So I think that this ticket, by itself, is redundant currently. If either of those other tickets is fixed, it won't be. * Fixing #12564 is likely to require generalizing (or otherwise changing) the form of type family LHSs, thus fixing this ticket inter alia. So, the upshot is: let's fix #12564 before #14645, and this ticket never needs to be considered again. :) I'm commenting on those two tickets, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:18:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:18:32 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.2dfb3fb869533829c7d4d643d3e23aad@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If this is fixed before #12564, then we might get #15905. See comment:10:ticket:15905. Tread carefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:19:27 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:19:27 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.a5723be37274702ca81cca983ab13c28@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): A fix for this ticket may also fix #15905. Well, at least the older plan, before comment:12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:42:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:42:50 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm Message-ID: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently Language.Haskell.TH.Syntax.addForeignFilePath only supports C, ObjC, C++, ObjC++ and objects (.o). I would like it to support assembly files (.s) too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:48:04 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:48:04 -0000 Subject: [GHC] #12770: Shrink list of RUNPATH entries for GHC libraries In-Reply-To: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> References: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> Message-ID: <060.055f49c0d37d2fe969d43cc848a1cd78@haskell.org> #12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 20:49:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 20:49:34 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types In-Reply-To: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> References: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> Message-ID: <062.c40e9a3acd95ba383ce3d0460eff1699@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: A few of us discussed this today, and came up with the following: * Treat anonymous wildcards `_` just like user-supplied metavariables, for the "I don't care" case. GHC should try to infer a value for the metavariable, and does not report anything (unless there is a genuine error, i.e. it is not possible to either solve or generalise over the metavariable). In particular, it becomes possible to write anonymous wildcards in more places, such as datatype and instance declarations. * Report named wildcards `_w`, including both type/kind and their instantiation (if one is determined by the context/expression), for the "I want help figuring out what this is" case. * We can optionally add flags to control this behaviour, e.g. to print out the inferred values for anonymous wildcards or suppress the named ones. * Add a separate syntactic cue indicating a partial type signature (e.g. use `:?` instead of `::`) for case 3. This avoids the oddity that introducing a wildcard means suddenly the expression no longer has a complete type signature. This probably needs a GHC proposal as the next step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 21:06:23 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 21:06:23 -0000 Subject: [GHC] #16181: ghc panic when using DerivingVia Message-ID: <046.af754f90ff560861dc62994c6b178ae4@haskell.org> #16181: ghc panic when using DerivingVia -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program results in a ghc panic: {{{#!hs {-# LANGUAGE DerivingVia #-} import Data.Functor.Const (Const(..)) import Data.Functor.Classes newtype FlipConst a b = FlipConst b deriving (Show1, Eq1) via (Const b) }}} Here is the output of the compile: {{{#!sh test/Spec/Contravariant.hs:52:13: error: • No instance for (Show b) arising from the 'deriving' clause of a data type declaration Possible fix: add (Show b) to the context of the deriving clause for ‘Show1 (FlipConst a)’ or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show1 (FlipConst a)) | 52 | deriving (Show1, Eq1) via (Const b) | ^^^^^ test/Spec/Contravariant.hs:52:13: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): No skolem info: [b_a3eO] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm using GHC 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 21:07:17 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 21:07:17 -0000 Subject: [GHC] #16181: ghc panic when using DerivingVia In-Reply-To: <046.af754f90ff560861dc62994c6b178ae4@haskell.org> References: <046.af754f90ff560861dc62994c6b178ae4@haskell.org> Message-ID: <061.47c78ae503b08aa50c9f3a15b4dad7e7@haskell.org> #16181: ghc panic when using DerivingVia -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: derivingvia Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chessai): * keywords: => derivingvia * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 21:17:57 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 21:17:57 -0000 Subject: [GHC] #15010: Application (warp) server crashing periodically with "TSO object entered" In-Reply-To: <047.a86a5c0a290e1c542e4015a537513efc@haskell.org> References: <047.a86a5c0a290e1c542e4015a537513efc@haskell.org> Message-ID: <062.45382cc4ff9d84086a6ad9e9889b13e2@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sseverance): I hit something similar last night. Unfortunately I don't have a way to make a repro but will provide what information I do have in case it helps eventually. Our app is a server, although not a web server. We make extensive use of the STM and there may be hundreds of threads running at a time. I would say there are a moderate amount of exceptions, mostly forced on us from their use in other libraries, as we tend not to use them. Happy to provide more specific info if I can. App was started with the following parameters: +RTS -N -qg1 -A5m -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:16:36 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:16:36 -0000 Subject: [GHC] #16151: GHC 8.6 build failure on ARM In-Reply-To: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> References: <045.5afb1cb140b308afa0fb8ae7cfe4449d@haskell.org> Message-ID: <060.2bed5012ad21f834a3e29946c86790e8@haskell.org> #16151: GHC 8.6 build failure on ARM ----------------------------------------+------------------------------ Reporter: dustin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by dustin): An artifact I built using this process is available via stack 13.x now. It seems to be working fine for me (with clang+llvm 6 installed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:24:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:24:32 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types In-Reply-To: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> References: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> Message-ID: <062.8df078bf32065b9904929695f8e6eaf2@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See https://github.com/ghc-proposals/ghc-proposals/pull/194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:28:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:28:28 -0000 Subject: [GHC] #16182: Retainer Profiling is broken Message-ID: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: profiling | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had a large program which I was trying to profile, and I noticed that the program always ran into a segfault when running with `+RTS -hr`. I was able to able to reliably get segfaults in both the `warp-tls` and `http- client-tls` packages, as well as a third large and independent package with essentially no overlapping dependencies. This led me to believe that the bug is in the retainer profiler itself, and is not (much) dependent on the code being profiled. To that point, I was able to reproduce the bug with the `bytestring` test suites. I've modified bytestring (attached) enough to make it compile with GHC 8.6.3*. To reproduce the segfault, run {{{ $ stack build --profile $ stack exec prop-compiled -- +RTS -hr }}} * Renamed the package to bytestring2 to avoid circular packages. * Removed a duplicate instance in tests/QuickCheckUtils.hs * Changed all test-suites to executables in the cabal file so that they could be compiled with profiling. I have confirmed the problem on Linux (Ubuntu 18.04), where prop-compiled quickly segfaults, and on Windows 10, where the program just hangs. [I observed the same behavior in all the other programs I tested: Linux sefaulted, and Windows just hung.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:28:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:28:50 -0000 Subject: [GHC] #16182: Retainer Profiling is broken In-Reply-To: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> References: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> Message-ID: <062.b95f43401d53365711593d886946fb6a@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "bytestring-0.10.8.2.zip" added. modified bytestring to easily demonstrate bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:31:48 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:31:48 -0000 Subject: [GHC] #16182: Retainer Profiling is broken In-Reply-To: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> References: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> Message-ID: <062.6dd8b36b4bb2af9aac5b2fa7960687b7@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): There have been a number of issues fixed in the profiler recently. Could you try with a recent build of GHC? You can download a generic linux bindist from here: https://gitlab.haskell.org/ghc/ghc/-/jobs/11660 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:41:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:41:50 -0000 Subject: [GHC] #16182: Retainer Profiling is broken In-Reply-To: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> References: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> Message-ID: <062.9808867aa42c6870d3c76dbf1740a2c0@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > I had a large program which I was trying to profile, and I noticed that > the program always ran into a segfault when running with `+RTS -hr`. I > was able to able to reliably get segfaults in both the `warp-tls` and > `http-client-tls` packages, as well as a third large and independent > package with essentially no overlapping dependencies. This led me to > believe that the bug is in the retainer profiler itself, and is not > (much) dependent on the code being profiled. To that point, I was able to > reproduce the bug with the `bytestring` test suites. > > I've modified bytestring (attached) enough to make it compile with GHC > 8.6.3*. To reproduce the segfault, run > > {{{ > $ stack build --profile > $ stack exec prop-compiled -- +RTS -hr > }}} > > * Renamed the package to bytestring2 to avoid circular packages. > * Removed a duplicate instance in tests/QuickCheckUtils.hs > * Changed all test-suites to executables in the cabal file so that they > could be compiled with profiling. > > I have confirmed the problem on Linux (Ubuntu 18.04), where prop-compiled > quickly segfaults, and on Windows 10, where the program just hangs. [I > observed the same behavior in all the other programs I tested: Linux > sefaulted, and Windows just hung.] New description: I had a large program which I was trying to profile, and I noticed that the program always ran into a segfault when running with `+RTS -hr`. I was able to able to reliably get segfaults in both the `warp-tls` and `http- client-tls` packages, as well as a third large and independent package with essentially no overlapping dependencies. This led me to believe that the bug is in the retainer profiler itself, and is not (much) dependent on the code being profiled. To that point, I was able to reproduce the bug with the `bytestring` test suites. I've modified bytestring (attached) enough to make it compile with GHC 8.6.3. To reproduce the segfault, run {{{ $ stack build --profile $ stack exec prop-compiled -- +RTS -hr }}} I have confirmed the problem on Linux (Ubuntu 18.04), where prop-compiled quickly segfaults, and on Windows 10, where the program just hangs. [I observed the same behavior in all the other programs I tested: Linux segfaulted, and Windows just hung.] Changes to bytestring: 1. Renamed the package to bytestring2 to avoid circular packages. 2. Removed a duplicate instance in tests/QuickCheckUtils.hs 3. Changed all test-suites to executables in the cabal file so that they could be compiled with profiling. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 22:59:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 22:59:32 -0000 Subject: [GHC] #16182: Retainer Profiling is broken In-Reply-To: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> References: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> Message-ID: <062.acf6a0bd9651de535ed2ecd4df74fe48@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): mpickering, I'm not able to build my example due to changes in GHC. Specifically, the `primitive` package fails to build, and that's not something I'm equipped to figure out. Perhaps you can try the attached example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 23:30:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 23:30:54 -0000 Subject: [GHC] #16181: ghc panic when using DerivingVia In-Reply-To: <046.af754f90ff560861dc62994c6b178ae4@haskell.org> References: <046.af754f90ff560861dc62994c6b178ae4@haskell.org> Message-ID: <061.8f936a5a58e198b760dfd8d1f21a572c@haskell.org> #16181: ghc panic when using DerivingVia -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15831 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: derivingvia => deriving * related: => #15831 Comment: Great test case. I have a strong hunch that this is a symptom of #15831. When I get around to fixing that, I'll check whether that fixes this ticket as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 23:31:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 23:31:19 -0000 Subject: [GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type In-Reply-To: <050.6e53147acb2c1b22346936cc921972a0@haskell.org> References: <050.6e53147acb2c1b22346936cc921972a0@haskell.org> Message-ID: <065.d3a4bdae96d2aaea8494f863cc01758b@haskell.org> #15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #16181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #16181 Comment: #16181 is likely a symptom of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 14 23:48:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Jan 2019 23:48:05 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications Message-ID: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you compile this file with GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind type F = $([t| (Maybe :: Type -> Type) Int |]) }}} You get two different results: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> (Maybe :: Type -> Type) Int $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> Maybe :: Type -> Type Int }}} Notice how in the GHC HEAD output, GHC forgets to put parentheses around `Maybe :: Type -> Type`, leading to the utterly nonsensical type `Maybe :: Type -> Type Int`. The commit that introduced this regression is [https://gitlab.haskell.org/ghc/ghc/commit/ae2c9b40f5b6bf272251d1f4107c60003f541b62 ae2c9b40f5b6bf272251d1f4107c60003f541b62]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 01:07:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 01:07:49 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.dffeb5acc392e6e68f11a780bf818e71@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > When you compile this file with GHC 8.6.3 and HEAD: > > {{{#!hs > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE TemplateHaskell #-} > {-# OPTIONS_GHC -ddump-splices #-} > module Bug where > > import Data.Kind > > type F = $([t| (Maybe :: Type -> Type) Int |]) > }}} > > You get two different results: > > {{{ > $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > Bug.hs:8:12-45: Splicing type > [t| (Maybe :: Type -> Type) Int |] > ======> > (Maybe :: Type -> Type) Int > > $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > Bug.hs:8:12-45: Splicing type > [t| (Maybe :: Type -> Type) Int |] > ======> > Maybe :: Type -> Type Int > }}} > > Notice how in the GHC HEAD output, GHC forgets to put parentheses around > `Maybe :: Type -> Type`, leading to the utterly nonsensical type `Maybe > :: Type -> Type Int`. > > The commit that introduced this regression is > [https://gitlab.haskell.org/ghc/ghc/commit/ae2c9b40f5b6bf272251d1f4107c60003f541b62 > ae2c9b40f5b6bf272251d1f4107c60003f541b62]. New description: When you compile this file with GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind type F = $([t| (Maybe :: Type -> Type) Int |]) }}} You get two different results: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> (Maybe :: Type -> Type) Int $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> Maybe :: Type -> Type Int }}} Notice how in the GHC HEAD output, GHC forgets to put parentheses around `Maybe :: Type -> Type`, leading to the utterly nonsensical type `Maybe :: Type -> Type Int`. The commit that introduced this regression is [https://gitlab.haskell.org/ghc/ghc/commit/bace26aadaafa4064e78f9ed088c1e2217221acc bace26aadaafa4064e78f9ed088c1e2217221acc]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 01:13:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 01:13:19 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.c39c4ed47900b91a91b763b1847a002d@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): @darchon: Thanks for looking into this. Do you know how to modify the cabal file to pass this option? I tried a few things but couldn't figure it out. (Otherwise I'm not sure how to build this for hackage.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 01:28:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 01:28:11 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.91ecf9c89c176dab38111c9b6af1bd6d@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Function types are also affected: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind type F = $([t| (Int :: Type) -> (Int :: Type) |]) }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190114: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:12-48: Splicing type [t| (Int :: Type) -> (Int :: Type) |] ======> Int :: Type -> Int :: Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 02:15:58 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 02:15:58 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.e63f3d1ad995b47bab33f20b3f451d59@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So are type family equations: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind $([d| type family F a where F (a :: Type) = Int |]) }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190114: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(9,30): Splicing declarations [d| type family F_a1B4 a_a1B5 where F_a1B4 (a_a1B6 :: Type) = Int |] ======> type family F_a4tB a_a4tC where F_a4tB a_a4tD :: Type = Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 02:48:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 02:48:11 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.808ee2e6885027c9edba98f51eee56f6@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/121 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/121 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 03:56:43 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 03:56:43 -0000 Subject: [GHC] #16184: GHC said to report a bug Message-ID: <048.f452635af3d80cbcdd6cb6c32ca3e341@haskell.org> #16184: GHC said to report a bug -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: panic, skolem | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to run {{{#!hs {-# LANGUAGE Rank2Types, PartialTypeSignatures #-} import Control.Monad newtype Search b = Search {optimum :: forall a. Ord a => (b -> a) -> b} instance Monad Search where return a = Search $ const a Search ma >>= f = Search $ \p -> optimum (f (ma (\a -> p (optimum (f a) p)))) p instance Functor Search where fmap = liftM instance Applicative Search where pure = return (<*>) = ap pair a b = Search $ \p -> if p a >= p b then a else b toList s = igo [] where igo ls = let x = optimum s (\x' -> x' `notElem` ls) in if x `elem` ls then ls else igo (x:ls) cantor :: Search (Integer -> Bool) cantor = let igo :: _ igo p n = q n (optimum cantor $ q n) where q n a = p undefined in Search igo main = return () }}} When run, it said {{{ source_file.hs:24:5: No instance for (Ord a) When checking that ‘igo’ has the specified type igo :: forall t a t1. (t -> a) -> t1 -> a Probable cause: the inferred type is ambiguous In the expression: let igo :: _ igo p n = q n (optimum cantor $ q n) where q n a = ... in Search igo In an equation for ‘cantor’: cantor = let igo :: _ igo p n = q n (optimum cantor $ q n) where ... in Search igo source_file.hs:26:15: Couldn't match type ‘t’ with ‘Integer -> Bool’ ‘t’ is untouchable inside the constraints (Ord a1) bound by a type expected by the context: Ord a1 => ((Integer -> Bool) -> a1) -> Integer -> Bool at source_file.hs:26:8-17ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): No skolem info: t_aU3[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Since it said to report a bug, I am. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 09:40:22 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 09:40:22 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.e7a22033158de9997eec1d002a2cab5d@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by osa1): Here are some notes. Compile and run: {{{ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug && ./Mult +RTS -DS }}} At one point we do a GC and continue: {{{ >>> bt #0 0x0000000000a0ed5d in StgRunIsImplementedInAssembler () at rts/StgCRun.c:370 #1 0x0000000000a0226a in schedule (initialCapability=0xd2c600 , task=0x242dd70) at rts/Schedule.c:452 #2 0x0000000000a03b7b in scheduleWaitThread (tso=0x4200105370, ret=0x0, pcap=0x7ffdbfd88f10) at rts/Schedule.c:2547 #3 0x0000000000a15e4b in rts_evalLazyIO (cap=0x7ffdbfd88f10, p=0xb3bb98, ret=0x0) at rts/RtsAPI.c:530 #4 0x0000000000a175d3 in hs_main (argc=1, argv=0x7ffdbfd89108, main_closure=0xb3bb98, rts_config=...) at rts/RtsMain.c:72 #5 0x0000000000463e78 in main () }}} If I step a few instructions I see these instructions being executed {{{ 0x0000000000a35d60 stg_ap_0_fast+336 mov 0x8(%rbp),%rax 0x0000000000a35d64 stg_ap_0_fast+340 mov 0x10(%rbp),%rbx 0x0000000000a35d68 stg_ap_0_fast+344 mov 0x18(%rbp),%rcx 0x0000000000a35d6c stg_ap_0_fast+348 add $0x20,%rbp 0x0000000000a35d70 stg_ap_0_fast+352 mov %rcx,%rdx }}} This is in `stg_ap_0_fast` and `%rbx` is supposed to be a FUN for a PAP, but it's actually collected by the GC: {{{ >>> print (StgClosure*)$rbx $27 = (StgClosure *) 0x42000b2868 >>> print *(StgClosure*)$rbx $28 = { header = { info = 0xaaaaaaaaaaaaaaaa, prof = { ccs = 0xaaaaaaaaaaaaaaaa, hp = { rs = 0xaaaaaaaaaaaaaaaa, ldvw = 12297829382473034410 } } }, payload = 0x42000b2880 } }}} Interestingly only some part of it is collected (the first 3 words). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 10:17:09 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 10:17:09 -0000 Subject: [GHC] #16184: GHC said to report a bug In-Reply-To: <048.f452635af3d80cbcdd6cb6c32ca3e341@haskell.org> References: <048.f452635af3d80cbcdd6cb6c32ca3e341@haskell.org> Message-ID: <063.78fffb056314803bc91abdb659c95436@haskell.org> #16184: GHC said to report a bug -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: wontfix | Keywords: panic, skolem Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Thanks. Seems OK with a more up to date GHC. E.g GHC 8.4 says {{{ T16184.hs:28:15: error: • Couldn't match type ‘a’ with ‘Bool’ ‘a’ is a rigid type variable bound by a type expected by the context: forall a. Ord a => ((Integer -> Bool) -> a) -> Integer -> Bool at T16184.hs:28:8-17 Expected type: ((Integer -> Bool) -> a) -> Integer -> Bool Actual type: ((Integer -> Bool) -> Bool) -> Integer -> Bool }}} I'm afraid we won't go back to fix 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 11:45:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 11:45:37 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm In-Reply-To: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> References: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> Message-ID: <060.d8cf28d1d7331aed5167be475316942d@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * owner: (none) => hsyl20 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 11:45:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 11:45:45 -0000 Subject: [GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. In-Reply-To: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> References: <049.3862587f91a2eaa8b116ce19f5a50e51@haskell.org> Message-ID: <064.c5066791966dec2b3fbee3ef550b1464@haskell.org> #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: worksforme | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by josef): * status: new => closed * resolution: => worksforme Comment: I'm not seeing the reported behaviour with the latest GHC. I get the expected type signatures: {{{ *Main> :t testCase1 testCase1 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () *Main> :t testCase2 testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () }}} So I'm closing this ticket. Reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 12:34:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 12:34:12 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm In-Reply-To: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> References: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> Message-ID: <060.b5a6c1a1534cbbb1f816022bde7e6888@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch Comment: Merge request: https://gitlab.haskell.org/ghc/ghc/merge_requests/122 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 13:10:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 13:10:46 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.4a6a4b9a4adc2b8c396182cfe2f48178@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: worksforme | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by josef): * status: new => closed * resolution: => worksforme Comment: This is fixed. With the latest GHC I get: {{{ Lib.hs:9:3: error: • Variable not in scope: pure :: () -> IO () • Perhaps you want to add ‘pure’ to the import list in the import of ‘Prelude’ (Lib.hs:5:1-19). | 9 | pure () | ^^^^ }}} I'm closing this ticket. Reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 13:17:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 13:17:01 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.829503ae942e71dbd9c5f4aab5db8407@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T16114 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/92 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => rename/should_fail/T16114 * resolution: => fixed * milestone: => 8.8.1 Comment: Landed in https://gitlab.haskell.org/ghc/ghc/commit/83a22066fbe136e4a984e8c90c1d3fd72b6ec4b9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:02:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:02:56 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.e6e5bc53d6bea7954ec23a58ac6339c4@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): +1, I hit the {{{foreignInterruptible}}} failure on GitLab as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:26:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:26:04 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy Message-ID: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:27:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:27:40 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.8dc9d0c0220c8ac44f47019711c88d04@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:30:58 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:30:58 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. Message-ID: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> #16186: Segfault when embedding data via file-embed. ----------------------------------------+--------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I made a minimal reproducible-ish example here: https://github.com/NorfairKing/nix-segfault-haskell and described it at length here: https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 The problem seems to occur (randomly) when literal strings are embedded via TH. By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:39:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:39:11 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.bd9825aee985475ee16b452dcd161124@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mpickering): Why are you embedding a 10mb file inside a program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:39:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:39:32 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.1d7517017ad69766b7f4758931ce162c@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by syd: Old description: > I made a minimal reproducible-ish example here: > > https://github.com/NorfairKing/nix-segfault-haskell > > and described it at length here: > > https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 > > The problem seems to occur (randomly) when literal strings are embedded > via TH. > By the way: to embed about 10MiB of data, 12 cores are being used at 100% > which seems mildly absurd. New description: GHC segfaults when embedding a bunch of data via `file-embed`: {{{ /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -idist/build/global- autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id segfault-0.0.0-G2YKYaaGIenGdA1YODfaB0 -hide-all-packages -Wmissing-home- modules -no-user-package-db -package-db /tmp/nix-build- segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 -package-id file-embed-0.0.10.1-JBj0CTa3b3pL2aTV19QFZK -XHaskell2010 Lib Paths_segfault -j12 -split-sections [2 of 2] Compiling Lib ( src/Lib.hs, dist/build/Lib.o ) Segmentation fault (core dumped) }}} I made a minimal reproducible-ish example here: https://github.com/NorfairKing/nix-segfault-haskell and described it at length here: https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 The problem seems to occur (randomly) when literal strings are embedded via TH. By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. It is relatively easy to obtain a core-dump file for it, and then we see the following in `gdb`: {{{ $ /usr/sbin/gdb /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc core.3212 GNU gdb (GDB) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc...(no debugging symbols found)...done. [New LWP 3232] [New LWP 3244] [New LWP 3252] [New LWP 3230] [New LWP 3231] [New LWP 3212] [New LWP 3213] [New LWP 3242] [New LWP 3226] [New LWP 3227] [New LWP 3233] [New LWP 3251] [New LWP 3225] [New LWP 3241] [New LWP 3245] [New LWP 3224] [New LWP 3214] [New LWP 3237] [New LWP 3235] [New LWP 3215] [New LWP 3238] [New LWP 3216] [New LWP 3248] [New LWP 3253] [New LWP 3234] [New LWP 3266] [New LWP 3239] [New LWP 3247] [New LWP 3250] [New LWP 3249] [New LWP 3240] [New LWP 3228] [New LWP 3229] [New LWP 3246] [New LWP 3236] [New LWP 3243] warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libthread_db-1.0.so line to your configuration file "/homeless-shelter/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/homeless-shelter/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc -B/'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fad21c9ae9f in abort () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 [Current thread is 1 (LWP 3232)] (gdb) bt #0 0x00007fad21c9ae9f in abort () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #1 0x00007fad21cdb2ac in __libc_message () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #2 0x00007fad21cdb2ce in __libc_fatal () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #3 0x00007fad21a536a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libpthread.so.0 #4 0x00007fad22d7fdd9 in waitCondition () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #5 0x00007fad22d6243b in yieldCapability () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #6 0x00007fad22d66e23 in schedule () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #7 0x00007fad22d6868c in scheduleWorker () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #8 0x00007fad21a4d5a7 in start_thread () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0 #9 0x00007fad21d5722f in clone () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 14:42:06 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 14:42:06 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.b72147d6bc700c8430a46924e51a3fc2@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by syd): > Why are you embedding a 10mb file inside a program? We are seeing similar problems when compiling other things, this just happened to be the most easy to reproduce. Maybe figuring this one out might help with other similar problems. In any case, GHC should never segfault but rather throw some sort of error. To answer your question: I'm embedding assets (pictures) in a web server. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 15:17:34 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 15:17:34 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.8458c15fe88f32f4ee53cb750386a3b5@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by syd): I have tried to make the example more minimal. Now I'm at the point where I used `ddump-splices` to replace the TH invocation entirely. Now I get a stack overflow: {{{ /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -idist/build/global- autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id segfault-0.0.0-G2YKYaaGIenGdA1YODfaB0 -hide-all-packages -Wmissing-home- modules -no-user-package-db -package-db /tmp/nix-build- segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 -package-id file-embed-0.0.10.1-JBj0CTa3b3pL2aTV19QFZK -XHaskell2010 Lib Paths_segfault -j12 -split-sections [2 of 2] Compiling Lib ( src/Lib.hs, dist/build/Lib.o ) : error: stack overflow }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 15:27:06 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 15:27:06 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.7f2bd9aade81d08b5284c2fcc3460ed2@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by syd): If I add `+RTS -K` to the original invocation, and now there is no longer a stack overflow error, but still a segfault. This time without any TH involved: {{{ /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -idist/build/global- autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id segfault-0.0.0-G2YKYaaGIenGdA1YODfaB0 -hide-all-packages -Wmissing-home- modules -no-user-package-db -package-db /tmp/nix-build- segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 -package-id file-embed-0.0.10.1-JBj0CTa3b3pL2aTV19QFZK -XHaskell2010 Lib Paths_segfault -j12 -split-sections +RTS -K [2 of 2] Compiling Lib ( src/Lib.hs, dist/build/Lib.o ) Segmentation fault (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 15:56:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 15:56:15 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.51896b82e06777a5e6d573b658177f6a@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by syd): I got it down to a much smaller command that still fails: {{{ /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make -hide-all-packages -no-user-package-db -package-db /tmp/nix-build- segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 src/Lib.hs -j12 +RTS -K [1 of 1] Compiling Lib ( src/Lib.hs, src/Lib.o ) Segmentation fault (core dumped) }}} Also, if I remove the `-j12`, it no longer segfaults. I also tried with `-j2` and that seems to work as well (no segfaults as far as I can tell). I also tried with `-j256` and it segfaults a _lot_ faster. The same goes for `-j4098`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 16:06:20 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 16:06:20 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.6565ea5c96080efb4ab141d330625e94@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by syd): I uploaded the smallest I could make the example here: https://raw.githubusercontent.com/NorfairKing/nix-segfault- haskell/master/Lib.hs Documentation about it here: https://github.com/NorfairKing/nix-segfault- haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 16:46:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 16:46:39 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.9c933669c1b3673029e96f80359e1fdc@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In GHC 8.4 we have {{{ thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} `lookupThName` ends up calling `lookupGlobalOccRn_maybe`; and (since I think we have an `Orig` at this point) thence `lookupExactOrOrig`, and thence `IfaceEnv.lookupOrig`. The latter * Looks up in the original-name cache * If the lookup fails, it makes a fresh external `Name`, updates the orig- name cache, and returns the `Name`. But in 8.6 we have {{{ thNameToGhcName th_name = do { names <- mapMaybeM lookup (thRdrNameGuesses th_name) -- Pick the first that works -- E.g. reify (mkName "A") will pick the class A in preference -- to the data constructor A ; return (listToMaybe names) } where lookup rdr_name | Just n <- isExact_maybe rdr_name -- This happens in derived code = return $ if isExternalName n then Just n else Nothing | Just (rdr_mod, rdr_occ) <- isOrig_maybe rdr_name = do { cache <- getOrigNameCache ; return $ lookupOrigNameCache cache rdr_mod rdr_occ } | otherwise = return Nothing }}} See: it looks up in the orig-name cache, but doesn't extend it on failure. That's what's going wrong. We just need to do what `lookupOrig` does. In HEAD some more refactoring has happened, which makes it easier. We want `thNameToGhcName` to call something very like `IfaceEnv.lookupOrigIO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 19:31:42 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 19:31:42 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.fa6c1709635cb147009baf12eeb07fde@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I've documented a workaround approach here: https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with-ghc.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:02:25 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:02:25 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.d142d4f9b6c36c93e2b236c64b42c846@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: worksforme | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jackkelly): This still fails for me on GHC 8.6.3, which is the latest I see on https://www.haskell.org/ghc . If I've missed a later version, or you've confirmed a fix on GHC HEAD, then please re-close: {{{ $ ghci Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Test.hs:7:3: error: Not in scope: ‘return’ Perhaps you want to add ‘return’ to the import list in the import of ‘Prelude’ (Test.hs:4:1-19). 7 | pure () | ^^^^^^^ Failed, no modules loaded. Prelude> }}} {{{ $ cat Test.hs {-# LANGUAGE RebindableSyntax #-} module Test where import Prelude (IO) foo :: IO () foo = do pure () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:03:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:03:17 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.e8da738b26c37097c2a445c4ffe86d73@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jackkelly): * owner: simonmar => (none) * status: closed => new * resolution: worksforme => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:06:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:06:17 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.0a5eb5a9e51542a82069f433bca3a9a3@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T16116a, | rename/should_fail/T16116b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/110 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => rename/should_compile/T16116a, rename/should_fail/T16116b * resolution: => fixed * milestone: => 8.8.1 Comment: Landed in https://gitlab.haskell.org/ghc/ghc/commit/e63518f5d6a93be111f9108c0990a1162f88d615. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:31:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:31:16 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.b24797a8b2f2ef64a0da5e2b35af1e7e@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by hsyl20): > By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. Incidentally, I've been working on this today: https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with-ghc.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:40:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:40:08 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.46eaf876fb8c73ac7e6b354801f18521@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mpickering): Nice post Sylvain. Really good motivation for #16180 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 21:40:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 21:40:27 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm In-Reply-To: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> References: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> Message-ID: <060.d447ea6dd4756346ae9e3670005f87d0@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Motivation for this is here: https://hsyl20.fr/home/posts/2019-01-15-fast- file-embedding-with-ghc.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 23:58:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 23:58:50 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.24ce90d2568898bb59ce9b19f2fe0e6b@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 15 23:59:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Jan 2019 23:59:27 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.f79578efc30bda07b3afcddb978bc3ef@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 00:01:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 00:01:18 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.64a1c3a98a5e5edd82450836dfd014b5@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always > `VisArg`. > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. We make a similar somewhat- arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 00:03:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 00:03:50 -0000 Subject: [GHC] #16187: Hadrian: Build fails when using absolute path for build root Message-ID: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> #16187: Hadrian: Build fails when using absolute path for build root -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian build | Operating System: Linux root relative absolute path | Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails: {{{ $ git clean -xdf $ ./boot && ./configure && ./hadrian/build.sh -o/tmp/build ... Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Hadrian/Builder.hs:70:5-23: * Depends on: /tmp/build01/stage2/lib/platformConstants at src/Hadrian/Utilities.hs:292:5-18: * Depends on: /tmp/build01/generated/platformConstants at src/Hadrian/Builder.hs:70:5-23: * Depends on: /tmp/build01/stage0/bin/deriveConstants at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package = Package {pkgType = Program, pkgName = "deriveConstants", pkgPath = "utils/deriveConstants"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:214:5-36: * Depends on: /tmp/build01/stage0/utils/deriveConstants/setup-config * Raised the exception: Error, rule finished running but did not produce file: /tmp/build01/stage0/utils/deriveConstants/setup-config CallStack (from HasCallStack): error, called at src/Development/Shake/Internal/Rules/File.hs:180:58 in shake-0.17.4-5aa097213b9663d13b00fb582ca77bb18e6d60c3b0376f0fc60fdbf22a73c6f4:Development.Shake.Internal.Rules.File }}} but changing `/tmp/build` to the relative path succeeds (something like `-o../../../../tmp/build`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 02:08:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 02:08:56 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) Message-ID: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles without issue on GHC 8.6.3: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Type.Bool (type (&&)) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data family Sing :: forall k. k -> Type data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True (%&&) :: forall (x :: Bool) (y :: Bool). Sing x -> Sing y -> Sing (x && y) SFalse %&& _ = SFalse STrue %&& a = a data RegExp :: Type -> Type where App :: RegExp t -> RegExp t -> RegExp t data instance Sing :: forall t. RegExp t -> Type where SApp :: Sing re1 -> Sing re2 -> Sing (App re1 re2) data ReNotEmptySym0 :: forall t. RegExp t ~> Bool type instance Apply ReNotEmptySym0 r = ReNotEmpty r type family ReNotEmpty (r :: RegExp t) :: Bool where ReNotEmpty (App re1 re2) = ReNotEmpty re1 && ReNotEmpty re2 sReNotEmpty :: forall t (r :: RegExp t). Sing r -> Sing (Apply ReNotEmptySym0 r :: Bool) sReNotEmpty (SApp sre1 sre2) = sReNotEmpty sre1 %&& sReNotEmpty sre2 blah :: forall (t :: Type) (re :: RegExp t). Sing re -> () blah (SApp sre1 sre2) = case (sReNotEmpty sre1, sReNotEmpty sre2) of (STrue, STrue) -> () }}} However, it panics on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190114 for x86_64-unknown-linux): buildKindCoercion Any ReNotEmpty re2_a1hm Bool t_a1hg Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:2427:9 in ghc:Coercion }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 02:10:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 02:10:25 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.33ce8f357e0e980783a2e996e8d43fc5@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's what you get when you compile the program with `-dcore-lint`: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: [RHS of ds_d1ur :: (Sing Any, Sing (ReNotEmpty re2_a1hm))] The type of this binder doesn't match the type of its RHS: ds_d1ur Binder's type: (Sing Any, Sing (ReNotEmpty re2_a1hm)) Rhs type: (Sing (Apply ReNotEmptySym0 re1_a1hl), Sing (ReNotEmpty re2_a1hm)) *** Offending Program *** blah :: forall t (re :: RegExp t). Sing re -> () [LclIdX] blah = \ (@ t_a1hg) (@ (re_a1hh :: RegExp t_a1hg)) (ds_d1uq :: Sing re_a1hh) -> let { ds_d1vi :: R:SingRegExp t_a1hg re_a1hh [LclId] ds_d1vi = ds_d1uq `cast` (D:R:SingRegExp0[0] _N _N :: Sing re_a1hh ~R# R:SingRegExp t_a1hg re_a1hh) } in case ds_d1vi of wild_00 { SApp @ re1_a1hl @ re2_a1hm co_a1hn sre1_aXI sre2_aXJ -> let { ds_d1ur :: (Sing Any, Sing (ReNotEmpty re2_a1hm)) [LclId] ds_d1ur = (sReNotEmpty @ t_a1hg @ re1_a1hl sre1_aXI, (sReNotEmpty @ t_a1hg @ re2_a1hm sre2_aXJ) `cast` (Sub (Sym (Sing _N (Sym (D:R:ApplyRegExpBoolReNotEmptySym0r[0] _N _N)))_N) :: Sing (Apply ReNotEmptySym0 re2_a1hm) ~R# Sing (ReNotEmpty re2_a1hm))) } in let { fail_d1v2 :: Void# -> () [LclId] fail_d1v2 = \ (ds_d1v3 [OS=OneShot] :: Void#) -> patError @ 'LiftedRep @ () "Bug.hs:(47,5)-(48,26)|case"# } in case ds_d1ur of wild_00 { (ds_d1uY, ds_d1uZ) -> let { ds_d1v0 :: R:SingBool Any [LclId] ds_d1v0 = ds_d1uY `cast` (D:R:SingBool0[0] _N :: Sing Any ~R# R:SingBool Any) } in case ds_d1v0 of wild_00 { __DEFAULT -> fail_d1v2 void#; STrue co_a1hA -> let { ds_d1v1 :: R:SingBool Any [LclId] ds_d1v1 = ds_d1uZ `cast` (D:R:SingBool0[0] _N :: Sing Any ~R# R:SingBool Any) } in case ds_d1v1 of wild_00 { __DEFAULT -> fail_d1v2 void#; STrue co_a1hD -> () } } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 02:53:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 02:53:19 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.b2d3d909d16174d9648156cb793b6867@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): I've spent a bunch of time trying to understand what's going on here. I don't actually think that the Cmm to LLVM pass is to blame. The faults seem to always occur in the std_blackhole function. I don't understand exactly how blackholes work, I think it's something like: I find a pointer to a closure, at the other end I might find: - a value, I'm done. - a closure, I evaluate that. - a blackhole, another HEC has beat me to this closure, so I'll wait for them to finish. Perhaps there's simply a barrier missing from std_blackhole. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:07 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.26e5daf5f9a07ed055bf7ed03790adb0@haskell.org> #16106: Remove PowerPC OS X (Darwin) support -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: patch Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/63 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"374e44704b64afafc1179127e6c9c5bf1715ef39/ghc" 374e4470/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="374e44704b64afafc1179127e6c9c5bf1715ef39" PPC NCG: Remove Darwin support Support for Mac OS X on PowerPC has been dropped by Apple years ago. We follow suit and remove PowerPC support for Darwin. Fixes #16106. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message In-Reply-To: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> References: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> Message-ID: <066.296d2eb0d813a27e80a779bd53220064@haskell.org> #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15816 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15362: Template Haskell ignores bad type family definitions In-Reply-To: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> References: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> Message-ID: <062.b2b5a8ab135bf06df247f5ee75fa0fa8@haskell.org> #15362: Template Haskell ignores bad type family definitions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15362 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:07 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments In-Reply-To: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> References: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> Message-ID: <062.1cc7fb99a9019c6ba5443e7bc4cd1471@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15360a, | th/T15360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5188 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.1b2ca187cd0fb53850652657bbcbfd99@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{b}, | typecheck/should_fail/T15592a Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.c91df1d9bba88666fa717918514463f4@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: #12045 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T15788 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.16510fc9d12d2341bf98f1aa1c0c642b@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T15793 Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.66e9da1fdd2675b2dd1ffab366eed6ac@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12045TH{1,2}, | typecheck/should_compile/T12045a, | typecheck/should_fail/T12045{b,c}, | parser/should_fail/T12045d, | parser/should_compile/T12045e Blocked By: | Blocking: 14579 Related Tickets: #15782 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.126c9b069a6ccfd7e125974a6c23721b@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15801 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types In-Reply-To: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> References: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> Message-ID: <062.91db5c16d368938e2d485cf0ff0462f3@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.ee19b09cf4152c40e1b9f4f45f820a63@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/polykinds/T15795, T15795a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.cbe1d7202c100432b2e05646a9a8bbe4@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15799 Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15807: GHC panic with visible kind applications In-Reply-To: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> References: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> Message-ID: <066.267fac8fc38283669bffb9a056452725@haskell.org> #15807: GHC panic with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15807 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16125: Broken Links in docs/users_guide/using-optimisation.rst In-Reply-To: <048.36371066852869c274db7532d64c9728@haskell.org> References: <048.36371066852869c274db7532d64c9728@haskell.org> Message-ID: <063.beb4e256f6caa77817c8f72b8300f4f2@haskell.org> #16125: Broken Links in docs/users_guide/using-optimisation.rst -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1574 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Gabor Greif ): In [changeset:"b565d418ff5f9501abecf130dafc2b9837460a96/ghc" b565d418/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b565d418ff5f9501abecf130dafc2b9837460a96" Fix broken links (#16125) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15797: GHC panic using visible kind application In-Reply-To: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> References: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> Message-ID: <066.99a4fa2895ce5cef1356f924b89009b2@haskell.org> #15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"17bd163566153babbf51adaff8397f948ae363ca/ghc" 17bd1635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17bd163566153babbf51adaff8397f948ae363ca" Visible kind application Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.4b7d5b3524d1d342bfe0fe94710c42c8@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T15798{a,b,c} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/48 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c121e33f9b039acf2ac6939af8bfafe593560039/ghc" c121e33f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c121e33f9b039acf2ac6939af8bfafe593560039" Add -Wmissing-deriving-strategies Warn users when -XDerivingStrategies is enabled but not used, at each potential use site. add -Wmissing-deriving-strategies Reviewers: bgamari, RyanGlScott Subscribers: andrewthad, rwbarton, carter GHC Trac Issues: #15798 Differential Revision: https://phabricator.haskell.org/D5451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16131: -ddump-cmm doesn't work when compiling cmm files In-Reply-To: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> References: <043.46cb14a076809a3edf8ae71b11cd5dc0@haskell.org> Message-ID: <058.ffb909f59b3080356497b491d427f195@haskell.org> #16131: -ddump-cmm doesn't work when compiling cmm files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"2880cb9840e268fdc33347a87a8276b03c227db8/ghc" 2880cb98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2880cb9840e268fdc33347a87a8276b03c227db8" Dump Cmm with -ddump-cmm when building .cmm files Fixes #16131 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.1777b35a163db5518e6b8480ee98107d@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Data.Fixed, | Show, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/data-fixed- | show-read Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ff42f3f6e85c1c3beca3bd9c5c034b667243239/ghc" 0ff42f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ff42f3f6e85c1c3beca3bd9c5c034b667243239" Add entry for #16031 to base/changelog.md }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.bac69faeb8431c64c04b9cd979299562@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Data.Fixed, | Show, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/data-fixed- | show-read Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"01b60b0e1ee57f882c5b729854343916c2295c51/ghc" 01b60b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01b60b0e1ee57f882c5b729854343916c2295c51" Fix precedence handling for Data.Fixed's Show instance (#16031) Use `showsPrec` instead of `show` to respect the precedence of the surrounding context. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16133: TH can sneak in TypeApplications without enabling the extension In-Reply-To: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> References: <050.a6a5b4b0b26093f7a9058b33066d2bc2@haskell.org> Message-ID: <065.b9e8f74b45c050182a2d639973ea20f4@haskell.org> #16133: TH can sneak in TypeApplications without enabling the extension -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T16133 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/77 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bbd58fb5f029b632e2d8977518723feee0737ba7/ghc" bbd58fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbd58fb5f029b632e2d8977518723feee0737ba7" Fix #16133 by checking for TypeApplications in rnExpr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide" In-Reply-To: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> References: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> Message-ID: <061.7592f23509b2e085629e092f810880b2@haskell.org> #15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4692 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"24b39ce53eedad4cefc30f6786542d2072d1f9b0/ghc" 24b39ce5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24b39ce53eedad4cefc30f6786542d2072d1f9b0" Remove OPTIONS_HADDOCK hide in favour for not-home GHC Trac Issues: #15447 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.9002757e6a1a6a358758110ba79306cc@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_fail/T16013 Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Phab:D5471, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/90 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6b70cf611e5ddc475edaa54b893d20990699ddb8/ghc" 6b70cf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b70cf611e5ddc475edaa54b893d20990699ddb8" Be pickier about unsaturated synonyms in :kind Summary: We currently permit any and all uses of unsaturated type synonyms and type families in GHCi's `:kind` command, which allows strange interactions like this one: ``` > :set -XTypeFamilies -XPolyKinds > type family Id (a :: k) > type instance Id a = a > type Foo x = Maybe > :kind! Id Foo ``` This is probably a stretch too far, so this patch moves to disallow unsaturated synonyms that aren't at the top level (we still want to allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt` with an additional `Bool` field to indicate if we are at the outermost level of the type being passed to `:kind` or not. See `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the full story. Test Plan: make test TEST=T16013 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: simonpj, goldfire, rwbarton, carter GHC Trac Issues: #16013 Differential Revision: https://phabricator.haskell.org/D5471 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.3b5414590068376add581920b3357fd0@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9ea8dcea3e5ba96808ef91028e0efde9d31f7272/ghc" 9ea8dcea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ea8dcea3e5ba96808ef91028e0efde9d31f7272" Hadrian: merge sections in profiling _p.a to .p_o for ghci This is the hadrain version of {D5169} * We build squashed .o and .p_o for ghci when `dynamicGhcPrograms` is `False` * We no longer build them for rts as ghci never loads it we need https://github.com/haskell/cabal/pull/5592 for cabal to copy the built `.p_o` file. Test Plan: ``` $ grep dynamicGhc hadrian/UserSettings.hs , dynamicGhcPrograms = return False $ touch ... $ hadrian/build.sh --flavour=user -j --digest-or $ find _build/stage1/libraries/ -name 'HS*-*.*o' | wc 62 62 3664 ``` ``` $ grep -C3 dynamicGhc hadrian/UserSettings.hs userFlavour :: Flavour userFlavour = performanceFlavour { name = "user" , dynamicGhcPrograms = return False } $ hadrian/build.sh -j --flavour=user test --verbose Unexpected results from: TEST="T3807 T9208 T9293 annth_make ghci057 haddock.Cabal haddock.base haddock.compiler" SUMMARY for test run started at Wed Dec 5 17:45:39 2018 PST 0:03:16 spent to go through 6708 total tests, which gave rise to 26015 test cases, of which 19290 were skipped 29 had missing libraries 6600 expected passes 88 expected failures 3 caused framework failures 0 caused framework warnings 1 unexpected passes 7 unexpected failures 0 unexpected stat failures $ find _build -name 'HSbase*.*o' _build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1 2.0.0.o _build/stage1/lib/x86_64-linux-ghc-8.7.20181204/base-4.12.0.0/HSbase-4.1 2.0.0.p_o _build/stage1/libraries/base/build/HSbase-4.12.0.0.o _build/stage1/libraries/base/build/HSbase-4.12.0.0.p_o ``` Reviewers: bgamari, simonmar, snowleopard Reviewed By: snowleopard Subscribers: alpmestan, rwbarton, carter GHC Trac Issues: #15779 Differential Revision: https://phabricator.haskell.org/D5270 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #661: Serious Data.HashTable bug In-Reply-To: <057.b31dce27f03c04ed28a019a7a7b1aa9c@haskell.org> References: <057.b31dce27f03c04ed28a019a7a7b1aa9c@haskell.org> Message-ID: <072.5380dedf9d06ea31a55a1b173a94fe6c@haskell.org> #661: Serious Data.HashTable bug -------------------------------------+--------------------------------- Reporter: jwr@… | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | -------------------------------------+--------------------------------- Changes (by Matthew Pickering ): * failure: => None/Unknown Comment: In [changeset:"6486c6e49c53e75f37ed732b38c5be7ae64785e8/ghc" 6486c6e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6486c6e49c53e75f37ed732b38c5be7ae64785e8" Hadrian: Add support for building stage3 This ticket enables the building of a `stage3` compiler by making the build logic more consistent and predictable in Hadrian. Two of the main changes are: 1. In order to build anything at stageN we use the package database present at stageN. Fixing #16069 2. `haddock` and `ghc-tags` are built as stage1 executables (with the stage1 compiler) rather than as stage2 compiler. Fixing [hadrian#661](https://github.com/snowleopard/hadrian/issues/661) In order to build a stage3 compiler, you have to set the new `finalStage` hadrian option to `Stage3`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.8eb42de5378fdf1829fea3226a6b5a1c@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alec Theriault ): In [changeset:"6b5ec08a4a64525bae87a8c2202688ffc6f86aa8/ghc" 6b5ec08a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b5ec08a4a64525bae87a8c2202688ffc6f86aa8" Check that libs found by GCC aren't folders Summary: We use 'gcc -B --print-file-name mylib.a' as a way of checking if 'gcc' can discover 'mylib.a' at the given location. However, this can break down if there is a folder caller 'mylib.a' that 'gcc' can discover. We can guard against this by explicitly checking that the path returned by 'gcc' is a file. This may seem like a far-fetched scenario, but since 3d17f1f10fc00540ac052f2fd03182906aa47e35, we look for libraries without any prefix or suffix (ie. 'extra-libraries: softfloat', we look for just 'softfloat' as well as 'softloat.a', 'softfloat.dll.a', etc.) which means that there might actusally be a folder of that name in one of the base locations. Reviewers: Phyx, bgamari, hvr, angerman Reviewed By: Phyx, angerman Subscribers: angerman, rwbarton, carter GHC Trac Issues: #16063 Differential Revision: https://phabricator.haskell.org/D5462 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian In-Reply-To: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> References: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> Message-ID: <064.4d8fc536178d73595fe0ee461782a59e@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"6486c6e49c53e75f37ed732b38c5be7ae64785e8/ghc" 6486c6e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6486c6e49c53e75f37ed732b38c5be7ae64785e8" Hadrian: Add support for building stage3 This ticket enables the building of a `stage3` compiler by making the build logic more consistent and predictable in Hadrian. Two of the main changes are: 1. In order to build anything at stageN we use the package database present at stageN. Fixing #16069 2. `haddock` and `ghc-tags` are built as stage1 executables (with the stage1 compiler) rather than as stage2 compiler. Fixing [hadrian#661](https://github.com/snowleopard/hadrian/issues/661) In order to build a stage3 compiler, you have to set the new `finalStage` hadrian option to `Stage3`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.6b2dc533e00a7c84662cafb6bfb7504d@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"82d1a88dec216d761b17252ede760da5c566007f/ghc" 82d1a88d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="82d1a88dec216d761b17252ede760da5c566007f" Implement a sanity check for CCS fields in profiling builds This helped me debug one of the bugs in #15508. I'm not sure if this is a good idea, but it worked for me, so wanted to submit this as a MR. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.0f3e6cc67b861339f1e208bf8a30ba5f@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"312c957f1cc7ff2ba3bc7eb258c477ed4a7e14c8/ghc" 312c957f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="312c957f1cc7ff2ba3bc7eb258c477ed4a7e14c8" testsuite: Add test for #16104 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 05:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 05:52:08 -0000 Subject: [GHC] #15471: Polymorphism, typed splices and type inference don't mix In-Reply-To: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> References: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> Message-ID: <064.6a49d4d4fb1da02c496ab1b801bcad40@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5286, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/106 -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"c2455e647501c5a382861196b64df3dd05b620a2/ghc" c2455e64/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2455e647501c5a382861196b64df3dd05b620a2" Run typed splices in the zonker Summary: This fixes #15471 In the typechecker we check that the splice has the right type but we crucially don't zonk the generated expression. This is because we might end up unifying type variables from outer scopes later on. Reviewers: simonpj, goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15471 Differential Revision: https://phabricator.haskell.org/D5286 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 08:14:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 08:14:33 -0000 Subject: [GHC] #16189: ParsedSource (especially module name source span) not available from Source Plugin Message-ID: <046.26448db793b569dc7b9c82871218de04@haskell.org> #16189: ParsedSource (especially module name source span) not available from Source Plugin -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: GHC API | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discovered in https://github.com/google/haskell- indexer/pull/89#discussion_r248081268, the `TcGblEnv` received by a Source Plugin doesn't seem to have a way of accessing the SrcSpan of the module name. When having access to the ParsedModule, it contains ParsedSource, which is `Located (HsModule GhcPs)`, whose inner datatype contains `Maybe (Located ModuleName)`, with the location's span pointing to the module name span. From `TcGblEnv` one can access the `ModSummary`, which has a `Maybe HsParsedModule`, but seems to be `Nothing` practically. I know this is a minor nit, but all other declarations are accessible by the source plugin so far, just this bit seems missing. Without this, haskell-indexer has to resort to source-code heuristics to get the module name span. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 08:30:48 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 08:30:48 -0000 Subject: [GHC] #15726: Don't include Haskeline (and others) in the global package DB In-Reply-To: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> References: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> Message-ID: <059.d85e7633dfca9bd43a995e85cbd2be76@haskell.org> #15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 bgamari]: > The only possible issue is that it would also be no longer possible to link against the `ghci` library that ships with GHC (since it depends upon `haskeline`). Are you ''sure'' the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8. ---- Replying to [ticket:15726 judah]: > Originally suggested by hvr here Note also that my suggestion/comment hinged on the condition that we > invest some time during the GHC 8.3.x dev cycle to figure out a way to decouple haskeline/terminfo from GHC's global pkg-db again so that haskeline can pick up new libraries (within reason) more easily but we haven't done this yet; hence we cannot deal with a new `exceptions` yet without dragging in `execptions` as well as its extra transitive dependencies into GHC's source-tree... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 09:55:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 09:55:02 -0000 Subject: [GHC] #16190: Speed up handling of large String literals Message-ID: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The idea would to try the following optimization for literal strings by adding a pass in the simplifier that does: 1. detect large string literals (> 2KB maybe? we would need to find a threshold) 2. append large strings into a temporary binary file, remember their offset and size 3. include the binary file into the compilation chain using ".incbin" in an assembler file (see the details here: https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with- ghc.html); add a fresh global module-specific symbol for the file, say "largestrings" 4. replace `Lit (Literal (LitString LARGE_BYTESTRING))` expressions with `unpackNBytes# (plusAddr (CLabel "largestrings") offset) size` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 10:03:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 10:03:28 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.98f69f57f279372eebb4c0f261327343@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Do you really need a separate binary file? That seems a bit complicated... Can't you just have literal data in the assembly file? There are a bunch of other tickets about literal strings: * #16014 * #15210 * #15113 * #13390 Would any of these get fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 10:34:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 10:34:47 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.a4ba3d6089fda200e3786ca6225ca16d@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): > Do you really need a separate binary file? That seems a bit complicated... Can't you just have literal data in the assembly file? Part of the optimization is to avoid ending up with binary data in textual form in a source file (e.g. assembly file). It's not complicated, GHC already has all the machinery to do it (addTempFile, addForeignFilePath, etc.). It should be worth trying in my opinion. > Would any of these get fixed? As far as I know, no. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 10:39:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 10:39:06 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.01618d9936702d411b1d9ce669f09814@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good catch. The culprit is here {{{ canDecomposableTyConAppOK ev eq_rel tc tys1 tys2 = case ev of ... CtWanted { ctev_dest = dest } -> do { traceTcS "canTCAppOk" (ppr bndrs $$ ppr (take 20 tc_roles) $$ ppr tys1 $$ ppr tys2) ; cos <- zipWith4M unifyWanted new_locs tc_roles tys1 tys2 ; setWantedEq dest (mkTyConAppCo role tc cos) } ... where loc = ctEvLoc ev role = eqRelRole eq_rel tc_roles = tyConRolesX role tc -- the following makes a better distinction between "kind" and "type" -- in error messages bndrs = tyConBinders tc is_kinds = map isNamedTyConBinder bndrs is_viss = map isVisibleTyConBinder bndrs kind_xforms = map (\is_kind -> if is_kind then toKindLoc else id) is_kinds vis_xforms = map (\is_vis -> if is_vis then id else flip updateCtLocOrigin toInvisibleOrigin) is_viss -- zipWith3 (.) composes its first two arguments and applies it to the third new_locs = zipWith3 (.) kind_xforms vis_xforms (repeat loc) }}} The equality we are solving is somthing like {{{ [WD] hole{co_a1hC} {0}:: (Sing @Bool (Apply @(RegExp t_a1hn[sk:1]) @Bool (ReNotEmptySym0 @t_a1hn[sk:1]) re1_a1hs[ssk:2]) :: *) GHC.Prim.~# (Sing @Bool a_a1hg[tau:2] :: *) }}} Turns out that for `Sing`, * its `tyConBinders` is `[]` * so `bndrs` is `[]` * so `new_locs` is `[]` * so `cos` is `[]` and we make a coercion `Refl Sing`,ignoring the arguments to `Sing`!! Utterly bogus. The silent assumption of this code is that in `T ty1 .. tyn` then the `tyConBinders` of `T` has length at least `n`. But that's not true for this data family; and in any case it might not be true of `K (*->*->*) Int Bool Char` where `K :: forall k. * -> k`; the number of of args depends on how you instantiate it. The only comment on this code is that it makes a "better distinction between kind and type", and I have no clue how it works. Moreover, it looks terribly smelly: there's a `zipWith3` followed by a `zipWith4M`. We can't ''really'' have seven things we want to zip!! Moreover the `zipWith3` is zipping two lists both constructed by `map`; and the arguments of those maps are ... more maps ... over the same thing, namely `bndrs`. Lots of huff and puff to do very little. Richard: all this comes from {{{ commit fb752133f45f01b27240d7cc6bce2063a015e51b Author: Richard Eisenberg Date: Tue Jul 18 14:30:40 2017 -0400 Track visibility in TypeEqOrigin }}} Could you possibly fix the bug, perhaps en route cleaning up the code and adding a Note with a concrete example to explain what is going on? Thanks! It might also be wise to ASSERT that that `cos` has the same length as `tys1` and `tys2`, which themselves should have the same length. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 10:39:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 10:39:51 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.c836a4e756c0a2d4b870fa1f410312d6@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:24:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:24:30 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) Message-ID: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program fails to compile with the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): mkNewTyConRhs MV_V [Int#, MVector s_a7WC[sk:1] a_a7WA[sk:1], MVector s_a7WC[sk:1] a_a7WA[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:65:27 in ghc:BuildTyCl }}} Removing either of the -funbox-strict-fields or StrictData pragma allow the code to compile correctly, but you do need to compile with -O to get the incorrect behaviour -ghci is fine loading the module. Although I wouldn't expect them to interact here as I don't get the same behaviour if I explicitly write out what would be implied by the flag and pragma: {{{ data V a = V {-# UNPACK #-} !a {-# UNPACK #-} !a deriving (Show) }}} just warnings about the unused UNPACKs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:25:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:25:35 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.00a86a0e17a5d38fc1eddd51da55da4a@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dbeacham): * Attachment "Lib.hs" added. Example program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:25:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:25:47 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.1a470f28eb05ad1be2dd972881cc69b6@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dbeacham): * Attachment "ghc-panic-deriving-unbox.cabal" added. cabal file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:26:24 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:26:24 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.42ef56d5c3d7f3b2f9a14929f00bac34@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dbeacham): * Attachment "splice" added. Output from -ddump-splices -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:27:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:27:40 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.2736f3105530761735d07110ddcda78f@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dbeacham: Old description: > The attached program fails to compile with the following error: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-unknown-linux): > mkNewTyConRhs > MV_V [Int#, MVector s_a7WC[sk:1] a_a7WA[sk:1], > MVector s_a7WC[sk:1] a_a7WA[sk:1]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/iface/BuildTyCl.hs:65:27 in > ghc:BuildTyCl > }}} > > Removing either of the -funbox-strict-fields or StrictData pragma allow > the code to compile correctly, but you do need to compile with -O to get > the incorrect behaviour -ghci is fine loading the module. > > Although I wouldn't expect them to interact here as I don't get the same > behaviour if I explicitly write out what would be implied by the flag and > pragma: > > {{{ > data V a = V {-# UNPACK #-} !a {-# UNPACK #-} !a > deriving (Show) > }}} > > just warnings about the unused UNPACKs. New description: The attached program {{{ {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module Lib where import qualified Data.Vector.Unboxed as V import Data.Vector.Unboxed.Deriving data V a = V {-# UNPACK #-} !a {-# UNPACK #-} !a deriving (Show) derivingUnbox "V" [t| forall a. V.Unbox a => V a -> (a, a) |] [| \(V a b) -> (a, b) |] [| \(a, b) -> V a b |] }}} fails to compile with the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): mkNewTyConRhs MV_V [Int#, MVector s_a7WC[sk:1] a_a7WA[sk:1], MVector s_a7WC[sk:1] a_a7WA[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:65:27 in ghc:BuildTyCl }}} Removing either of the -funbox-strict-fields or StrictData pragma allow the code to compile correctly, but you do need to compile with -O to get the incorrect behaviour -ghci is fine loading the module. Although I wouldn't expect them to interact here as I don't get the same behaviour if I explicitly write out what would be implied by the flag and pragma: {{{ data V a = V {-# UNPACK #-} !a {-# UNPACK #-} !a deriving (Show) }}} just warnings about the unused UNPACKs. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:35:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:35:17 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.a9aecee2f9a4e5952ea67b99e439b46d@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That looks bad. Is it possible to repro this without relying on vector? And without TH? Perhaps by writing out the code that TH generates? Could it be #15523? Does it happen in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:52:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:52:43 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.97a289fff6859e77a7d35b25cfc00197@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): I just experienced the same `T1288_ghci` failure from comment:3. Can that be marked as broken, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 11:57:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 11:57:37 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.654ff8814a96081ec15dcc04c965859c@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by osa1): I think unreg is unreliable in general. Unless we mark all tests as broken unreg validate will break again at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:13:34 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:13:34 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.66d241318241e34e3c154106b1856a0e@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Really, unravelFamInstPats should panic I agree. Might you find a moment to make it so? Esp now we have a concrete case where chaos happens if we don't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:18:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:18:21 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.d5f0f303f9fada936f01150c119a0e3d@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dbeacham): Here's a much shorter example without TH or Vector. {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE StrictData #-} {-# OPTIONS_GHC -funbox-strict-fields #-} module Lib where data V a = V a a deriving (Show) data family Test a newtype instance Test (V a) = V_V (a, a) }}} with this error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): applyTypeToArgs Expression: V_V @ a_a1BO dt_a1R2 dt_a1R3 Type: forall a. (a, a) -> Test (V a) Args: [TYPE: a_a1BO, dt_a1R2, dt_a1R3] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:234:14 in ghc:CoreUtils }}} Removing either StrictData or -funbox-strict-fields makes it compile. Maybe of interest that removing StrictData but adding in explicit strictness compiles OK: {{{ {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -funbox-strict-fields #-} module Lib where data V a = V !a !a deriving (Show) data family Test a newtype instance Test (V a) = V_V (a, a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:30:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:30:02 -0000 Subject: [GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 In-Reply-To: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> References: <048.4011039e03c880e22d341bd4426a61f4@haskell.org> Message-ID: <063.b79f5f11b20061c6d843dde36baf6c6a@haskell.org> #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => hs-boot Comment: I'm snowed under at the moment, but this ticket would not be hard to solve for someone who is wanting to help in typechecker-land. I know what to do, and can advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:32:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:32:23 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.4f55cb3535425cdce0dc935566d1c82f@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, Wiki Page: | Phab:D5229 -------------------------------------+------------------------------------- Comment (by simonpj): > I was originally hopeful that we could avoid generating any explicit kind signatures and exclusively use visible kind application. Yes I agree with your analysis. Visible kind application (VKA) can only be used for Specified arguments, and user-defined types can have Inferred arguments. So yes, if there are no Inferred ones (a common case) you can use VKA; but not if not. Annoying! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:34:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:34:08 -0000 Subject: [GHC] #15602: PAP invariant of pointer tagging does not hold in profiling builds (was: PAP invariant of pointer tagging does not hold) In-Reply-To: <043.62b25bafb1242d8e47aeeb30451990fd@haskell.org> References: <043.62b25bafb1242d8e47aeeb30451990fd@haskell.org> Message-ID: <058.48721ce90b0f56fdb1def8cf6af73514@haskell.org> #15602: PAP invariant of pointer tagging does not hold in profiling builds -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15508, #13767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * component: Compiler => Profiling Comment: I think this only happens when profiling. I'm not sure if the problem is in the RTS or generated code (compiler). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 12:36:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 12:36:38 -0000 Subject: [GHC] #16192: Simplifier does not preserve dependency ordering of the program Message-ID: <043.690b9acd46a2e850fe12edd11ab6a9f6@haskell.org> #16192: Simplifier does not preserve dependency ordering of the program -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this some time ago, but I thought this is expected, because there's a comment in CoreLint that mentions this: {{{ lintCoreBindings dflags pass local_in_scope binds = initL dflags flags in_scope_set $ addLoc TopLevelBindings $ lintLetBndrs TopLevel binders $ -- Put all the top-level binders in scope at the start -- This is because transformation rules can bring something -- into use 'unexpectedly' ... }}} However talking to SPJ today he mentioned that in Core we should actually preserve dependency ordering, hence this ticket. I'll update with a reproducer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 13:50:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 13:50:08 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.9cbd0777b43fb61898555f1ec159d5ef@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: #16085 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * related: => #16085 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 13:50:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 13:50:22 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.72a889738649812e6b7ff5a7e4b6c48e@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15467 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15467 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 14:00:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 14:00:31 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.206cce7b9c860c271c1f26e9b660bc19@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #16141 * milestone: => 8.8.1 Comment: Thanks for the simpler test case. This is a duplicate of #16141, which has been fixed upstream in HEAD. (Perhaps we should merge the fix into the upcoming 8.6.4 release, though, given the volley of tickets about this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 14:01:45 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 14:01:45 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.0ffaeaa212709a6d100c01a4b8ca61a9@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.4 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16141 Blocked By: | Blocking: Related Tickets: #16191 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge * related: => #16191 * milestone: 8.8.1 => 8.6.4 Comment: Given the severity of this bug, and that fact that there have been multiple bug reports about this (see #16191 for another one), I'll optimistically mark this as a candidate for merging into the upcoming 8.6.4 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 14:16:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 14:16:03 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures Message-ID: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> #16193: Nondeterministic T15897 timeout failures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm noticing sporadic test failures for `T15897`. Here is [https://ghc- gitlab.s3.amazonaws.com/43/4c/434c9b5ae514646bbd91b50032ca579efec8f22bf0b4aac12e65997c418e0dd6/2019_01_16/12262/16763/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190116T140554Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190116 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=a8e95f4ef77f5dc5fd38a8ee4f4ccdbb25c1671f8be3b767de21004a2dd407a8 one recent example]: {{{ Wrong exit code for T15897()(expected 0 , actual 99 ) *** unexpected failure for T15897(profasm) }}} This was on the `validate-x86_64-linux-deb9-unreg` CI configuration, although it's unclear to me if the problem is exclusive to that configuration or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 14:20:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 14:20:39 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures In-Reply-To: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> References: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> Message-ID: <065.c47a732f362a9fe3fc6162ac9b39ab96@haskell.org> #16193: Nondeterministic T15897 timeout failures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The problem is the test taking too much time and timing out. We should either find another test (hard) or just bump the timeout multiplier again (easy, I did this before for this test but apparently it's not enough sometimes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 14:34:29 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 14:34:29 -0000 Subject: [GHC] #16101: Write a nix expression to enter a shell with specified build artifact In-Reply-To: <049.4fe1634b22bf6d60c068c0561bb19b09@haskell.org> References: <049.4fe1634b22bf6d60c068c0561bb19b09@haskell.org> Message-ID: <064.0f62336fa07f8f209b1adeaf177cd43e@haskell.org> #16101: Write a nix expression to enter a shell with specified build artifact -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Fixed, see https://github.com/mpickering/ghc-artefact-nix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 15:33:04 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 15:33:04 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor Message-ID: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: DeriveFunctor | Operating System: Unknown/Multiple deriving RankNTypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails (`deriving stock Functor`) (data type comes from [https://duplode.github.io/extras/applicative-archery-manuscript.pdf Applicative Archery]) {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.7.20181230: https://www.haskell.org/ghc/ :? for help Prelude> :set prompt "> " > :set -XRankNTypes -XDeriveFunctor -ddump-deriv > :set -dsuppress-idinfo -dsuppress-coercions -dsuppress-type-applications -dsuppress-uniques -dsuppress-module-prefixes > newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving Functor ==================== Derived instances ==================== Derived class instances: instance Functor (T cat) where fmap f (MkT a1) = MkT ((\ b2 b3 -> f (b2 ((\ b1 -> b1) b3))) a1) (<$) z (MkT a1) = MkT ((\ b3 b4 -> (\ b2 -> z) (b3 ((\ b1 -> b1) b4))) a1) Derived type family instances: :4:62: error: • Couldn't match type ‘forall xx. cat xx xx’ with ‘cat xx0 xx0’ Expected type: cat xx0 xx0 -> a Actual type: (forall xx. cat xx xx) -> a • In the first argument of ‘\ b2 b3 -> f (b2 ((\ b1 -> b1) b3))’, namely ‘a1’ In the first argument of ‘MkT’, namely ‘((\ b2 b3 -> f (b2 ((\ b1 -> b1) b3))) a1)’ In the expression: MkT ((\ b2 b3 -> f (b2 ((\ b1 -> b1) b3))) a1) When typechecking the code for ‘fmap’ in a derived instance for ‘Functor (T cat)’: To see the code I am typechecking, use -ddump-deriv • Relevant bindings include a1 :: (forall xx. cat xx xx) -> a (bound at :4:62) fmap :: (a -> b) -> T cat a -> T cat b (bound at :4:62) :4:62: error: • Couldn't match type ‘forall xx. cat xx xx’ with ‘cat xx1 xx1’ Expected type: cat xx1 xx1 -> b Actual type: (forall xx. cat xx xx) -> b • In the first argument of ‘\ b3 b4 -> (\ b2 -> z) (b3 ((\ b1 -> b1) b4))’, namely ‘a1’ In the first argument of ‘MkT’, namely ‘((\ b3 b4 -> (\ b2 -> z) (b3 ((\ b1 -> b1) b4))) a1)’ In the expression: MkT ((\ b3 b4 -> (\ b2 -> z) (b3 ((\ b1 -> b1) b4))) a1) When typechecking the code for ‘<$’ in a derived instance for ‘Functor (T cat)’: To see the code I am typechecking, use -ddump-deriv • Relevant bindings include a1 :: (forall xx. cat xx xx) -> b (bound at :4:62) (<$) :: a -> T cat b -> T cat a (bound at :4:62) > }}} Generates odd code {{{#!hs fmap .. = MkT ((\ b2 b3 -> f (b2 ((\ b1 -> b1) b3))) a1) }}} It works fine (in HEAD) to `deriving newtype Functor` (it didn't in 8.2 where I checked) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 15:38:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 15:38:50 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor In-Reply-To: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> References: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> Message-ID: <066.927e89c05b7da2718b2e2e74d1153749@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: DeriveFunctor | deriving RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Fortunately `-XDerivingVia` handles it {{{ > newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving Functor via ((->) (forall xx. cat xx xx)) ==================== Derived instances ==================== Derived class instances: instance Functor (T cat) where fmap = coerce @((a -> b) -> ((forall (xx :: TYPE LiftedRep). cat xx xx) -> a) -> (forall (xx :: TYPE LiftedRep). cat xx xx) -> b) @((a -> b) -> T cat a -> T cat b) (fmap @((->) (forall (xx :: TYPE LiftedRep). cat xx xx) :: TYPE LiftedRep -> TYPE LiftedRep)) :: forall (a :: TYPE LiftedRep) (b :: TYPE LiftedRep). (a -> b) -> T cat a -> T cat b (<$) = coerce @(a -> ((forall (xx :: TYPE LiftedRep). cat xx xx) -> b) -> (forall (xx :: TYPE LiftedRep). cat xx xx) -> a) @(a -> T cat b -> T cat a) ((<$) @((->) (forall (xx :: TYPE LiftedRep). cat xx xx) :: TYPE LiftedRep -> TYPE LiftedRep)) :: forall (a :: TYPE LiftedRep) (b :: TYPE LiftedRep). a -> T cat b -> T cat a Derived type family instances: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 15:46:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 15:46:35 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.61b449ca3f83aaaa0ad9b58c3db1fc95@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T16059{a,c,d,e} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: upstream => closed * testcase: => typecheck/should_fail/T16059{a,c,d,e} * resolution: => fixed * blocking: 16140 => * milestone: 8.10.1 => 8.8.1 Comment: Landed in https://gitlab.haskell.org/ghc/ghc/commit/9dc56b61ae10cb26ec8b2bc132ae6c9b620707a8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 16:07:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 16:07:01 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary Message-ID: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Almost certainly due to c2455e647501c5a382861196b64df3dd05b620a2 A trivial program now causes a core lint error due to an out-of-scope dictionary. {{{ module A where foo :: Code (IO ()) foo = [|| return () ||] }}} {{{ module B where main :: IO () main = $$foo }}} {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: return @ IO $dMonad_a4od @ () () Out of scope: $dMonad_a4od :: Monad m_a4oc[tau:0] [LclId] *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "B"#) main :: IO () [LclIdX] main = return @ IO $dMonad_a4od @ () () end Rec } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 16:29:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 16:29:54 -0000 Subject: [GHC] #16196: Update README.md to reflect gitlab Message-ID: <051.dc075844b9fb0e22f65a5b097621ec09@haskell.org> #16196: Update README.md to reflect gitlab -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://gitlab.haskell.org/ghc/ghc's [https://gitlab.haskell.org/ghc/ghc/blob/master/README.md README.md] still points to > Check out the source code from git > {{{ > $ git clone --recursive git://git.haskell.org/ghc.git > }}} there are probably other other places that need to be updated, marking as *newcomer* -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 16:39:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 16:39:37 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor In-Reply-To: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> References: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> Message-ID: <066.230db0c1c70db0f86eea16097293a8a6@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: DeriveFunctor | deriving RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is rather delicate. Here is the instance you likely have in your head: {{{#!hs instance Functor (T cat) where fmap f (MkT g) = MkT (\x -> f (g x)) }}} As `-ddump-deriv` reveals, this isn't quite the code that GHC is producing. It's actually producing this: {{{#!hs instance Functor (T cat) where fmap f (MkT g) = MkT ((\g' x -> f (g' x)) g) }}} Normally, these two implementations would be equivalent. However, because `g` has a higher-rank type `forall xx. cat xx xx`, applying `(\g' x -> f (g' x))` to `g` causes its type to be instantiated with a skolem `xx0`. This is why you get this error message: {{{ Couldn't match type ‘forall xx. cat xx xx’ with ‘cat xx0 xx0’ }}} There are advantages to generating code similar to the second instance. In more complicated examples (e.g., `newtype T a = MkT (Int -> Int -> a)`), using the unapplied form allows for a more compositional code-generation strategy that doesn't have to reason about substituting in arguments. In short, could this be fixed? Theoretically speaking, yes, but it would require a lot of work for not much gain. Personally, I'm inclined to just require users to write out this particular instance by hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 16:57:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 16:57:16 -0000 Subject: [GHC] #13191: Make liftA2 a method of Applicative In-Reply-To: <045.6e3d12c3796dddf03258e755974fce1f@haskell.org> References: <045.6e3d12c3796dddf03258e755974fce1f@haskell.org> Message-ID: <060.7324bf827eebf9963db4ae298c8dd8b6@haskell.org> #13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3031 Wiki Page: | -------------------------------------+------------------------------------- Old description: > Some functors support implementations of `liftA2` that are considerably > faster than the usual definition. Furthermore, some people see `liftA2` > as more intuitive and fundamental to the idea of `Applicative` than `<*>` > is. > > This has been discussed on the libraries list in > https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and > (as an official proposal) in > https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. > All who expressed an opinion favored the proposal. One (David Menendez) > specified that his support was weak. The others (Conal Elliot, Kris > Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either > supported the proposal strongly or merely indicated they were "+1". Conal > Elliot wrote: > [[BR]] > [[BR]] > > > +1. > > > > I also sometimes define a specialized `liftA2` and then use it to > define > > `(<*>)`, which then gets used to define the real `liftA2`. > > > > I think of `liftA2` as playing a role similar to `foldMap` and > `traverse`, while > > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- > compose > > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > > `traverse.traverse.traverse`. With functor composition, it's so much > nicer to > > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and > `Traversable`) > > rather than `liftA2 (<*>)`. > [[BR]] > > Wren Romano wrote > [[BR]] > [[BR]] > > > I'm also all for adding liftA2 to the class and have noticed this > > inefficiency/asymmetry when working on the class hierarchies for other > > languages > [[BR]] > > Kris NuttyCombe wrote > [[BR]] > [[BR]] > > > I'm in favor of this change. From my perspecive, liftA2 is actually the > > fundamental Applicative operation, an <*> is merely a convenient > > isomorphism. When I'm teaching, showing the symmetry between the > following > > always seems to help students: > > > > fmap :: (a -> b) -> f a -> f b > > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > > flip (>>=) :: (a -> f b) -> f a -> f b > > > > <*> is obviously exceptionally useful in practice. But liftA2 seems > like the > > more essential shape of that operation. New description: Some functors support implementations of `liftA2` that are considerably faster than the usual definition. Furthermore, some people see `liftA2` as more intuitive and fundamental to the idea of `Applicative` than `<*>` is. This has been discussed on the libraries list in https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and (as an official proposal) in https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. All who expressed an opinion favored the proposal. One (David Menendez) specified that his support was weak. The others (Conal Elliott, Kris Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either supported the proposal strongly or merely indicated they were "+1". Conal Elliott wrote: [[BR]] [[BR]] > +1. > > I also sometimes define a specialized `liftA2` and then use it to define > `(<*>)`, which then gets used to define the real `liftA2`. > > I think of `liftA2` as playing a role similar to `foldMap` and `traverse`, while > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- compose > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > `traverse.traverse.traverse`. With functor composition, it's so much nicer to > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and `Traversable`) > rather than `liftA2 (<*>)`. [[BR]] Wren Romano wrote [[BR]] [[BR]] > I'm also all for adding liftA2 to the class and have noticed this > inefficiency/asymmetry when working on the class hierarchies for other > languages [[BR]] Kris NuttyCombe wrote [[BR]] [[BR]] > I'm in favor of this change. From my perspecive, liftA2 is actually the > fundamental Applicative operation, an <*> is merely a convenient > isomorphism. When I'm teaching, showing the symmetry between the following > always seems to help students: > > fmap :: (a -> b) -> f a -> f b > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > flip (>>=) :: (a -> f b) -> f a -> f b > > <*> is obviously exceptionally useful in practice. But liftA2 seems like the > more essential shape of that operation. -- Comment (by conal): Fix spelling of my last name ("Elliott"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 18:10:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 18:10:23 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.a5345d7a02d49ad66d3d997d3e78b54d@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by nh2): Yes, indeed the linker approach solves that. Note though that this ticket isn't really about embedding files, it's about there being a code path in GHC that leads to segfaults (which should never happen); embedding files is just the way we managed to reproduce the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 18:38:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 18:38:20 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.b1bbc81f8d1597ea550afd6607dc1b11@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The good news is that #16059 has been fixed. The downside is that I just discovered that the only reason that I managed to get the program in this ticket to work (after implementing the suggestion in comment:3) is //because// of #16059! That is to say, when I try implementing comment:3 now, GHC's improved type validity-checker now rejects the program in this ticket. Bummer. It looks like calling `check_pred_ty` isn't enough—there must be something deeper that needs to be changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 19:00:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 19:00:06 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.daab42fbc8fa3404202e98328a67584b@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For reference, here is why `check_pred_ty` rejects the program in this ticket under the new-and-improved type validity-checker. We start with this type: {{{#!hs (Functor f, F1 f) }}} `check_pred_ty` calls `check_ty`, at which point we discover that this type is headed by a constraint tuple type constructor, so we call `check_arg_type` on each of its arguments. As a consequence, we switch the `ve_rank` in the `ValidityEnv` to `tyConArgMonoType`. We eventually check `F1 f` and, in turn, check `forall a. Eq (f a)` using `check_type` (if we were using the old type validity-checker, we would have stopped at `F1 f`!). Since `forall a. Eq (f a)` is a polytype, we must check it using `forAllAllowed ve_rank`. But our `ve_rank` is still `tyConArgMonoType`, and `forAllAllowed` returns `False` for `MonoType`s! So GHC ultimately decides to reject it. ----- What can be done about this? One conceivable route is to add a special case to `check_type` for applications of constraint tuple type constructors and, if so, don't call `check_arg_type` and instead call some other function which ensures that `ve_rank` is permissive enough to handle polytypes. There is precedent for this already—see `check_ubx_tuple`. On the other hand, I don't think this would fix the problem entirely. The issue is that we want to accept this: {{{#!hs f :: (Functor f, forall a. Eq (f a)) => Int }}} While simultaneously rejecting this: {{{#!hs g :: Proxy (Functor f, forall a. Eq (f a)) -> Int }}} But in both cases, `forall a. Eq (f a)` is directly underneath an application of a constraint tuple tycon, so if we always switch `ve_rank` to something permissive whenever we detect an application of a constraint tuple tycon, then I believe that GHC would accept //both// programs, which isn't what we want. I think that we a finer-grained criterion than this, but I'm not sure what that would be... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 19:05:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 19:05:38 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.276087fbac59b7401e55a679d7370d55@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): It's a bit hard to say with certainty that this is GHC's fault, especially since the program referenced in comment:7 uses a function from `bytestring` library that's explicitly labeled as unsafe. My first inclination would be to label this as a `bytestring` bug, not a GHC one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 19:32:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 19:32:30 -0000 Subject: [GHC] #15726: Don't include Haskeline (and others) in the global package DB In-Reply-To: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> References: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> Message-ID: <059.b1a43a856fb64f1d5ffee5679112558d@haskell.org> #15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have emailed Judah about this. Hopefully he'll be able to cut another minor release without the `exceptions` dependency for 8.8. Then I suppose we'll need to figure out how to make progress on this ticket for 8.10. > Are you sure the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8. Not at all; can you refresh our memories on what those issues were? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 19:33:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 19:33:43 -0000 Subject: [GHC] #16189: ParsedSource (especially module name source span) not available from Source Plugin In-Reply-To: <046.26448db793b569dc7b9c82871218de04@haskell.org> References: <046.26448db793b569dc7b9c82871218de04@haskell.org> Message-ID: <061.f868d410ba2ff78bae08dee1d0b224d2@haskell.org> #16189: ParsedSource (especially module name source span) not available from Source Plugin -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.10.1 Component: GHC API | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alanz (added) * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 19:47:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 19:47:40 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.20c08ebecd20fda4e77593b57ac3f6d2@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: > I find a pointer to a closure, at the other end I might find: > > * a value, I'm done. > * a closure, I evaluate that. > * a blackhole, another HEC has beat me to this closure, so I'll wait for them to finish. That pretty much sums it up. You can find more on blacholing and its consequences for multicore support in "Runtime Support for Multicore Haskell." > Perhaps there's simply a barrier missing from std_blackhole. I think it's more likely that the missing barrier is elsewhere. The `stg_BLACKHOLE` entry code contains the following loop: {{{#!c p = StgInd_indirectee(node); if (GETTAG(p) != 0) { return (p); } info = StgHeader_info(p); if (info == stg_IND_info) { // This could happen, if e.g. we got a BLOCKING_QUEUE that has // just been replaced with an IND by another thread in // wakeBlockingQueue(). // See Note [BLACKHOLE pointing to IND] in sm/Evac.c goto retry; } }}} Note how if the indirectee is tagged we return it immediately. Consequently there is the potential for a race if a thunk update is missing a barrier since the thread entering the blackhole could see the pointer to `StgInd_indirectee(node)` before the closure at that location becomes visible. `stg_upd_frame` relies on the `updateWithIndirection` macro to perform the thunk update. Intriguingly, there doesn't appear to be any barrier between the writes initializing the result closure from the thunk computation and the update of the indirectee. Rather, there is only a write barrier **after** the indirectee update. This seems wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:02:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:02:03 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.ff16f7868fc853efe61df8b4ac1e1e05@haskell.org> #16186: Segfault when embedding data via file-embed. ---------------------------------+---------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): syd, very interesting. Can you reproduce this with 8.6? If not, is it possible that you are running out of memory? This sounds very much like #14329 although I believe this was fixed in 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:04:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:04:19 -0000 Subject: [GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide" In-Reply-To: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> References: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> Message-ID: <061.f62f146922616da50d0f895e937f80c0@haskell.org> #15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: fixed | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:08:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:08:32 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.fecdfb61147dd5111ad039a578814aa2@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, Wiki Page: | Phab:D5229 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: 12045 => Comment: To recap, there are two distinct-but-related tasks here: 1. Make GND-generated code use VKA to instantiate arguments in specified positions. 2. Minimize the number of explicit kind signatures generated by GND code by using the approach discussed in comment:21. Althought (1) and (2) can technically be done independently, it's only the combination of the two that will make it so that the original program in this ticket generate code with no explicit kind signatures adorning its `'Proxy` types. I'll look into this approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:32:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:32:01 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.9740e79770cbc78d2a58b02ccb856046@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Most of the test failures I see in that log are of the form: {{{ =====> T9776(normal) 1124 of 6521 [0, 129, 0] cd "./driver/T9776.run" && "/private/tmp/ghc-20190108-10122-1a2rxgx/ghc-8.6.3/inplace/bin/ghc-stage2" -c T9776.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -drule-check--- /dev/null 2019-01-08 18:24:33.000000000 +0000 +++ ./driver/write_interface_oneshot.run/write_interface_oneshot.run.stderr.normalised 2019-01-08 18:24:33.000000000 +0000 @@ -0,0 +1 @@ +make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. }}} This is because `-j` was passed to `make test`. Try removing `-j` from the `make test` invocation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:34:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:34:20 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.2761edc3ba30e1138e08b7a7ba48b3de@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by bgamari): Did this ever happen, Peter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 20:38:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 20:38:31 -0000 Subject: [GHC] #15873: move to llvm 7 for 8.8.1 In-Reply-To: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> References: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> Message-ID: <060.a7688649616ad8644d024a7a9434d2d8@haskell.org> #15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been done in 929363b7454f8ec843908514f7e3c3da1666b000. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 21:32:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 21:32:18 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.7e75b2025f9a32eeeed2bec1db0eeb89@haskell.org> #16186: Segfault when embedding data via file-embed. -------------------------------------+------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * failure: None/Unknown => Compile-time crash or panic Old description: > GHC segfaults when embedding a bunch of data via `file-embed`: > > {{{ > /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make > -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf > dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir > dist/build -i -idist/build -isrc -idist/build/autogen -idist/build > /global-autogen -Idist/build/autogen -Idist/build/global-autogen > -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this- > unit-id segfault-0.0.0-G2YKYaaGIenGdA1YODfaB0 -hide-all-packages > -Wmissing-home-modules -no-user-package-db -package-db /tmp/nix-build- > segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace > -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 -package-id > file-embed-0.0.10.1-JBj0CTa3b3pL2aTV19QFZK -XHaskell2010 Lib > Paths_segfault -j12 -split-sections > [2 of 2] Compiling Lib ( src/Lib.hs, dist/build/Lib.o ) > Segmentation fault (core dumped) > }}} > > I made a minimal reproducible-ish example here: > > https://github.com/NorfairKing/nix-segfault-haskell > > and described it at length here: > > https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 > > The problem seems to occur (randomly) when literal strings are embedded > via TH. > By the way: to embed about 10MiB of data, 12 cores are being used at 100% > which seems mildly absurd. > > It is relatively easy to obtain a core-dump file for it, and then we see > the following in `gdb`: > > {{{ > $ /usr/sbin/gdb /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/ghc core.3212 > GNU gdb (GDB) 8.2.1 > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/ghc...(no debugging symbols found)...done. > [New LWP 3232] > [New LWP 3244] > [New LWP 3252] > [New LWP 3230] > [New LWP 3231] > [New LWP 3212] > [New LWP 3213] > [New LWP 3242] > [New LWP 3226] > [New LWP 3227] > [New LWP 3233] > [New LWP 3251] > [New LWP 3225] > [New LWP 3241] > [New LWP 3245] > [New LWP 3224] > [New LWP 3214] > [New LWP 3237] > [New LWP 3235] > [New LWP 3215] > [New LWP 3238] > [New LWP 3216] > [New LWP 3248] > [New LWP 3253] > [New LWP 3234] > [New LWP 3266] > [New LWP 3239] > [New LWP 3247] > [New LWP 3250] > [New LWP 3249] > [New LWP 3240] > [New LWP 3228] > [New LWP 3229] > [New LWP 3246] > [New LWP 3236] > [New LWP 3243] > > warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- > glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by > your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libthread_db-1.0.so > line to your configuration file "/homeless-shelter/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/homeless-shelter/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the > shell: > info "(gdb)Auto-loading safe path" > > warning: Unable to find libthread_db matching inferior's thread library, > thread debugging will not be available. > > warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- > glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by > your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > > warning: Unable to find libthread_db matching inferior's thread library, > thread debugging will not be available. > Core was generated by `/nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/ghc -B/'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007fad21c9ae9f in abort () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 > [Current thread is 1 (LWP 3232)] > (gdb) bt > #0 0x00007fad21c9ae9f in abort () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 > #1 0x00007fad21cdb2ac in __libc_message () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 > #2 0x00007fad21cdb2ce in __libc_fatal () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 > #3 0x00007fad21a536a6 in pthread_cond_wait@@GLIBC_2.3.2 () > from /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- > glibc-2.27/lib/libpthread.so.0 > #4 0x00007fad22d7fdd9 in waitCondition () > from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so > #5 0x00007fad22d6243b in yieldCapability () > from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so > #6 0x00007fad22d66e23 in schedule () > from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so > #7 0x00007fad22d6868c in scheduleWorker () > from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- > ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so > #8 0x00007fad21a4d5a7 in start_thread () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0 > #9 0x00007fad21d5722f in clone () from /nix/store > /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 > }}} New description: GHC itself segfaults when embedding a bunch of data via `file-embed`: {{{ /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -idist/build/global- autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id segfault-0.0.0-G2YKYaaGIenGdA1YODfaB0 -hide-all-packages -Wmissing-home- modules -no-user-package-db -package-db /tmp/nix-build- segfault-0.0.0.drv-2/package.conf.d -package-db dist/package.conf.inplace -package-id base-4.11.1.0 -package-id bytestring-0.10.8.2 -package-id file-embed-0.0.10.1-JBj0CTa3b3pL2aTV19QFZK -XHaskell2010 Lib Paths_segfault -j12 -split-sections [2 of 2] Compiling Lib ( src/Lib.hs, dist/build/Lib.o ) Segmentation fault (core dumped) }}} I made a minimal reproducible-ish example here: https://github.com/NorfairKing/nix-segfault-haskell and described it at length here: https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 The problem seems to occur (randomly) when literal strings are embedded via TH. By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. It is relatively easy to obtain a core-dump file for it, and then we see the following in `gdb`: {{{ $ /usr/sbin/gdb /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc core.3212 GNU gdb (GDB) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc...(no debugging symbols found)...done. [New LWP 3232] [New LWP 3244] [New LWP 3252] [New LWP 3230] [New LWP 3231] [New LWP 3212] [New LWP 3213] [New LWP 3242] [New LWP 3226] [New LWP 3227] [New LWP 3233] [New LWP 3251] [New LWP 3225] [New LWP 3241] [New LWP 3245] [New LWP 3224] [New LWP 3214] [New LWP 3237] [New LWP 3235] [New LWP 3215] [New LWP 3238] [New LWP 3216] [New LWP 3248] [New LWP 3253] [New LWP 3234] [New LWP 3266] [New LWP 3239] [New LWP 3247] [New LWP 3250] [New LWP 3249] [New LWP 3240] [New LWP 3228] [New LWP 3229] [New LWP 3246] [New LWP 3236] [New LWP 3243] warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libthread_db-1.0.so line to your configuration file "/homeless-shelter/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/homeless-shelter/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. warning: File "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/ghc -B/'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fad21c9ae9f in abort () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 [Current thread is 1 (LWP 3232)] (gdb) bt #0 0x00007fad21c9ae9f in abort () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #1 0x00007fad21cdb2ac in __libc_message () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #2 0x00007fad21cdb2ce in __libc_fatal () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 #3 0x00007fad21a536a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv- glibc-2.27/lib/libpthread.so.0 #4 0x00007fad22d7fdd9 in waitCondition () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #5 0x00007fad22d6243b in yieldCapability () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #6 0x00007fad22d66e23 in schedule () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #7 0x00007fad22d6868c in scheduleWorker () from /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf- ghc-8.4.3/lib/ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so #8 0x00007fad21a4d5a7 in start_thread () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0 #9 0x00007fad21d5722f in clone () from /nix/store /g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 }}} -- Comment: Replying to [comment:11 RyanGlScott]: > [...] since the program [...] uses a function from `bytestring` library that's explicitly labeled as unsafe. My first inclination would be to label this as a `bytestring` bug, not a GHC one. There's a misunderstanding: The segfault is at **compile time**, the `bytestring` function in question is never executed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 21:46:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 21:46:21 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.01ec85673d91f0a3e98f5c7144cfa947@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:8 bgamari]: > Did this ever happen, Peter? I got sidetracked with the port to FreeBSD. I will work on it tomorrow morning (European time). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 22:11:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 22:11:31 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.5f3b25bba3ea00362b4bec1c3ed23742@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): At the moment we call `check_pred_ty` in exactly two situations: 1. On each element of the context of a type built with `=>`, such as `forall a. (Eq a, Show a) => blah` 2. On the RHS of a type synonym whose RHS kind is `Constraint`. Your example `g :: Proxy (Functor f, forall a. Eq f a) -> Int` is neither of these, so none of the `check_pred_ty` stuff will happen; and indeed it should not. Notice the difference between (1) and (2). In (1) we call `check_pred_ty` on ''each element of'' the context; in (2) we call `check_pred_ty` on the ''entire RHS''. If the entire RHS is `(c1, c2)` we will ''not'' call `check_pred_ty` on `c1` and `c2`. But if we want to treat the two the same, ''we probably should''. Now, `check_pred_ty` currently works like this: {{{ check_pred_ty env dflags ctxt expand pred = do { check_type ve pred ; check_pred_help False env dflags ctxt pred } }}} First we call ordinary `check_type`; then we make extra checks. That's already a bit odd: why look at `pred` twice? Moreover, the firset thing we do in the "extra checks" is to call `classifyPredType` which has a case just for constraint tuples. So the obvious path is this: move the `check_type` stuff into `check_pred_help`. So `checkPred` would look something like this: {{{ check_pred_ty ve dflags ctxt expand pred = go False pred where rank = ..as now.. ve = ..as now.. go under_syn pred | Just pred' <- tcView pred -- As now = go True pred' go under_syn pred = case classifyPredType pred of EqPred rep t1 t2 -> check_eq_pred ve rep t1 t2 ClassPred cls tys | isCTupleClass cls -> check_tuple_pred under_syn ve pred tys | otherwise -> check_class_pred ve pred cls tys ..etc.. -- Notice that check_eq_pred checks the complete predicate -- including the validity of t1 and t2 check_eq_pred ve rep t1 t2 = do { check_arg_type ve t1 ; check_arg_type ve t1 ; checkTcM (rep == ReprEq || xopt LangExt.TypeFamilies dflags || xopt LangExt.GADTs dflags) (eqPredTyErr env pred) } check_tuple_pred under_syn ve pred tys = do { mapM_ check_pred tys -- <------------------- Aha! use check_pred here! ; ..then as now.. } }}} This will fix another current bug, namely: {{{ f :: (Eq a, (Show a, forall b. Eq (f b), Ord a) => blah }}} This has a nested constraint tuple, and will currently be rejected. But it should not be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 22:23:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 22:23:43 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.255ec2ca167eea284854969f44dc96b3@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/128 Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always > `VisArg`. > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. We make a similar somewhat- > arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a > `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. Current state is at: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. We make a similar somewhat- arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 22:31:29 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 22:31:29 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.170be0824a522743278f5759102471e6@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > Current state is at: > https://gitlab.haskell.org/ghc/ghc/merge_requests/128 > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always > `VisArg`. > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. We make a similar somewhat- > arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a > `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. Current state is at: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} * Add an `AnonArgFlag` to data constructor `Anon` in `TyCoRep` {{{ data TyCoBinder = Named TyCoVarBinder -- A type-lambda binder | Anon AnonArgFlag Type -- A term-lambda binder. Type here can be CoercionTy. -- Visibility is determined by the AnonArgFlag }}} and to data constructor `AnonTCB` (in `TyCon`) {{{ data TyConBndrVis = NamedTCB ArgFlag | AnonTCB AnonArgFlag }}} The latter is needed because the promoted version of a GADT data constructor is a TyCon with some invisible (equality) arguments. Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. We make a similar somewhat- arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 16 23:19:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Jan 2019 23:19:23 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary In-Reply-To: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> References: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> Message-ID: <064.32ef332672bd863442885bc8386ef7f1@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I tried adding a call to `captureTopConstraints` around the `zonkTcGblEnv` where the splices are run but it doesn't seem to capture any evidence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 00:56:28 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 00:56:28 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.3c2a90c24227de16ead2ab2b2d8163cd@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for the very detailed advice. After implementing the plan in comment:12, the original program in this ticket is now accepted. But we're not out of the woods yet, since several test cases now topple over. I'll try to summarize the issues below: * Certain programs no longer need `QuantifiedConstraints` to typecheck, even though they should. For instance, this typechecks: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where f :: (forall a. Eq a) => Int f = 42 }}} Likely reason: the place where we check if `QuantifiedConstraints` is enabled (`checkTcM (forAllAllowed rank)` in `check_type`) is no longer reachable from `check_pred_ty`, since it no longer invokes `check_type`. Similarly, it's now possible to sneak impredicativity into constraints, as the following program is now accepted, even though it shouldn't be: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RankNTypes #-} module Bug where f :: Num (forall a. a) => Int f = 42 }}} * `TypeApplications` now require language extensions that they didn't before. For instance, the `T12447` test case used to be work: {{{ ghci> :set -XRankNTypes -XConstraintKinds -XTypeApplications ghci> deferEither @(_ ~ _) }}} Now, it produces the following error: {{{ + +:1:1: + Illegal equational constraint _0 ~ _1 + (Use GADTs or TypeFamilies to permit this) + In the expression: deferEither @(_ ~ _) *** unexpected failure for T12447(ghci) }}} Depending on one's perspective, this might be a desirable outcome. But it is a break from convention, so it's worth noting. Another example from the `TypeRep` test case: {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( TypeRep.hs, TypeRep.o ) TypeRep.hs:41:11: error: • Non type-variable argument in the constraint: Eq Int (Use FlexibleContexts to permit this) • In the second argument of ‘($)’, namely ‘rep @((Eq Int, Eq String) :: Constraint)’ In a stmt of a 'do' block: print $ rep @((Eq Int, Eq String) :: Constraint) In the expression: do print $ rep @String print $ rep @Char print $ rep @Int print $ rep @Word .... *** unexpected failure for TypeRep(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 02:29:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 02:29:55 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 Message-ID: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With -O0, the attached code prints: {{{ > /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O0 src/foo.hs; and ./src/foo [1 of 1] Compiling Main ( src/foo.hs, src/foo.o ) [Optimisation flags changed] Linking src/foo ... ("exec",0) ("depth",0) ("exec",1) ("depth",0) }}} But with -O1, it prints: {{{ > /usr/local/ghc/ghc-8.4.1.0/bin/ghc -O1 src/foo.hs; and ./src/foo [1 of 1] Compiling Main ( src/foo.hs, src/foo.o ) Linking src/foo ... ("depth",0) ("depth",0) }}} Reproduced with 8.4.1 and 8.6.2. Doesn't seem to happen under 8.2.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 02:30:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 02:30:33 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.1b7fc1f02dd76e8838913d11bb56f516@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alang9): * Attachment "foo.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 04:18:37 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 04:18:37 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.e5991651e2798cdbe848359f35d97fb9@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 04:42:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 04:42:39 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.e6184437a1ca19fd82d23d6ef743a366@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): 1) what rewrite rules are firing ? 2) more importantly: does disabling rewrite rules under 01 or 02 fix the bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 06:01:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 06:01:54 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.3486dee04307b8a43ed2e0df33f9fcf6@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alang9): The bug still appears with `-O1 -fno-enable-rewrite-rules`. The following BUILTIN rules still fire: {{{ Rule fired: Class op null (BUILTIN) Rule fired: Class op foldl' (BUILTIN) Rule fired: Class op null (BUILTIN) Rule fired: Class op foldl' (BUILTIN) Rule fired: Class op >>= (BUILTIN) Rule fired: Class op return (BUILTIN) Rule fired: Class op return (BUILTIN) Rule fired: Class op enumFromTo (BUILTIN) Rule fired: Class op foldl' (BUILTIN) Rule fired: Class op fromInteger (BUILTIN) Rule fired: integerToInt (BUILTIN) Rule fired: Class op show (BUILTIN) Rule fired: Class op show (BUILTIN) Rule fired: Class op return (BUILTIN) Rule fired: Class op showsPrec (BUILTIN) Rule fired: Class op showsPrec (BUILTIN) Rule fired: Class op showsPrec (BUILTIN) Rule fired: Class op showsPrec (BUILTIN) Rule fired: ># (BUILTIN) Rule fired: ==# (BUILTIN) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 06:36:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 06:36:41 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.9d0afaeff3da0f2a8f34d21271359974@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: I made a smaller test case that I believe exhibits the same issue: {{{#!hs data T = T !Bool data Box a = Box a f :: Int -> T -> Box Bool f n t | n <= 0 = case t of T b -> Box b | otherwise = f (n-2) t f1 :: Int -> Bool -> Box Bool f1 n t | n <= 0 = f (-n) $! T t | otherwise = f1 (n-2) t g :: Int -> Bool g k = if k <= 0 then error "crash" else False {-# NOINLINE g #-} main :: IO () main = case f1 4 (g 0) of Box _ -> return () }}} With ghc-8.6.2, the above program crashes when compiled with -O0 but not when compiled with -O1. It looks like the issue has something to do with strictness analysis. After the first pass of the demand analyzer, `f` gets the following strictness signature: {{{ Str=m, }}} This means `f` is deeply strict in the second argument. This is correct in the sense that `f n (T undefined)` is undefined, but it doesn't mean `f` is going to deeply evaluate the second argument (it doesn't). However, it looks like this strong strictness signature is then used in the next simplifier pass to justify dropping the implicit `seq` on `t` (arising from the field strictness of `T`) in `f1`. This `seq` is in fact the only thing in the program that forces the error thunk, so dropping it changes the program behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 07:57:59 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 07:57:59 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.e0ab4c5d4066c8b5fef375958670d602@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by domenkozar): Upstream issue: https://gitlab.com/twittner/bytestring-conversion/issues/2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 08:52:36 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 08:52:36 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.c5eccf2982cc63ca02c31cf887a0d61d@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Certain programs no longer need QuantifiedConstraints to typecheck, even though they should Aha! That is easily dealt with. Now predicates have their own validity checker, `check_pred_ty`. So we can put the quantified-constraint check in the `ForAllPred` branch of the `classifyPredType` case analysis; and nowhere else. We don't need to monkey with the rank anymore! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 08:57:46 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 08:57:46 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.36d15c05be553759d59a796fd6ec21da@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > TypeApplications now require language extensions that they didn't before. This one is more mysterious to me. * The arguments to a VTA is checked with `checkValidType` (see `TcHsType.tcHsTypeApp`). * `checkValidType` uses `check_type`, not `check_pred_ty`. So how come we end up in `check_pred_ty`? I don't think we want to; e.g. `Eq Int` is a perfectly fine instantiation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:08:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:08:21 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.b484530504ebdc21d96299c1a2ee6803@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fxcoudert): Does the testsuite not support parallel build? It used to work without issue in previous versions, such 8.4.4. If not, it is really disappointing given it takes such a long time to run already… if it needs to be run without parallel execution, we probably will disable it in Homebrew, which will sadly lower the quality of our checks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:25:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:25:52 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.62d3e1da6c1bc3c9abe090d663c20e29@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by trommler): Merge request 130: https://gitlab.haskell.org/ghc/ghc/merge_requests/130 As with the fix for HEAD I tested on powerpc64le but not on 32-bit PowerPC. Sorry for the delay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:33:09 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:33:09 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.390baaa460ea526a457e8c81e9effd0d@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I can reproduce this with 8.6, but not with HEAD, so I think perhaps it is fixed. Hooray. Indeed we have made some recent changes to the handling of strictness on data constructors: {{{ commit d77501cd5b9060e38acd50e11e0c5aae89d75b65 Author: Simon Peyton Jones Date: Wed Dec 12 17:22:07 2018 +0000 Improvements to demand analysis This patch collects a few improvements triggered by Trac #15696, and fixing Trac #16029 * Stop making toCleanDmd behave specially for unlifted types. This special case was the cause of stupid behaviour in Trac #16029. And to my joy I discovered the let/app invariant rendered it unnecessary. (Maybe the special case pre-dated the let/app invariant.) Result: less special-case handling in the compiler, and better perf for the compiled code. * In WwLib.mkWWstr_one, treat seqDmd like U(AAA). It was not being so treated before, which again led to stupid code. * Update and improve Notes There are .stderr test wibbles because we get slightly different strictness signatures for an argumment of unlifted type: rather than for Int# rather than for Int commit d549c081f19925dd0e4c70d45bded0497c649d49 Author: Ben Gamari Date: Tue Dec 11 13:34:47 2018 -0500 dmdAnal: Move handling of datacon strictness to mkWWstr_one Previously datacon strictness was accounted for when we demand analysed a case analysis. However, this results in pessimistic demands in some cases. For instance, consider the program (from T10482) data family Bar a data instance Bar (a, b) = BarPair !(Bar a) !(Bar b) newtype instance Bar Int = Bar Int foo :: Bar ((Int, Int), Int) -> Int -> Int foo f k = case f of BarPair x y -> case burble of True -> case x of BarPair p q -> ... False -> ... We really should be able to assume that `p` is already evaluated since it came from a strict field of BarPair. However, as written the demand analyser can not conclude this since we may end up in the False branch of the case on `burble` (which places no demand on `x`). By accounting for the data con strictness later, applied to the demand of the RHS, we get the strict demand signature we want. See Note [Add demands for strict constructors] for a more comprehensive discussion. commit c5b477c29127d8375b3f23d37f877278b52547f6 Author: Ömer Sinan Ağacan Date: Mon Oct 15 13:48:53 2018 -0400 Fix cardinality change of fields in addDataConStrictness }}} And indeed the strictness of `f` is now {{{ Str=m, }}} I had previously regarded these patches as clean-ups, improving the generated code, rather than actual bug fixes. So your example is very interesting: it shows that the "clean-up" actually fixed a bug. Ben/Omer: could you add comment:4 as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:45:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:45:55 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.ea6235eab16d1fb4466d0bbab4d74981@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mpickering): Looks like a darwin specific issue, perhaps even a nix on darwin specific issue. I can't reproduce this on NixOS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:56:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:56:07 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.b9c78f3c886d5db338747a960b1f8d37@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: closed => new * resolution: wontfix => Comment: Haskell programs killed on startup by OOM on OpenShift. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:56:26 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:56:26 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.7f68b1991c0a74914e15c228aab75a75@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 09:59:24 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 09:59:24 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.732ff28a501c914633c1c2b7dcfe0845@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mpickering): I an reproduce this with nix on darwin though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 10:07:06 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 10:07:06 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.785861dd1bfadc2e12e31462366c3174@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have experimented with this in the following branch: https://gitlab.haskell.org/hsyl20/ghc/tree/hsyl20-T16190 It adds a GHC command-line flag to choose the threshold (in bytes) above which the strings are dumped in a binary file (e.g. `./inplace/bin/ghc- stage2 -fbinary-string-threshold=200`). The current implementation performs the transformation in the tidy pass. I'm not sure if it is the best place to do it. The included `bench_literal.sh` script generates an Haskell source file which prints a string literal and then benches the time required to compile it. Below are the results for different string lengths. With this test, the optimization starts to be really noticeable for string literals >500K. || Size || No optimization || Threshold 100 || Gain || || 128 || 0.730 || 0.770 || -5% || || 3K || 0.731 || 0.829 || -13% || || 30K || 0.736 || 0.805 || -9% || || 100K || 0.804 || 0.856 || -6% || || 500K || 1.038 || 0.912 || +12% || || 1M || 1.342 || 1.101 || +18% || || 2M || 1.926 || 1.446 || +25% || || 3M || 2.539 || 1.805 || +29% || || 30M || 20.182 || 10.244 || +49% || I couldn't test with TH generated string literals as it crashes the compiler because some names become garbage with the optimization enabled. We should probably only enable the optimization if we generate an actual linked object file. It isn't done yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 10:48:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 10:48:38 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.d87b479f0841d8cd4be9d03d4dde652a@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What does "no optimisation" and "threshold 100" mean? I though if "threshold 100" means that if a literal is > 100 bytes then it is put in the extra file, then every single line will do that, so the threshold is irrelevant. I wonder why it every slows down? Just the extra file handling? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 10:57:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 10:57:07 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.773acf612f2cd90bf4736b88362e4323@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 11:11:32 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 11:11:32 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.6d7899a63b109492da394cf04e5e5204@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): > What does "no optimisation" and "threshold 100" mean? I though if "threshold 100" means that if a literal is > 100 bytes then it is put in the extra file, then every single line will do that, so the threshold is irrelevant. Indeed with threshold=100 the optimization applies in every tested case to the string literal in the file. I could have written "optimization enable" but then we would have wondered what the threshold was (in particular if the optimization was triggered for small strings). > I wonder why it every slows down? Just the extra file handling? I guess it's extra file handling (generation and linking) + the traversal of the module bindings. With the small strings, this test seems to be consistently worse with the optimization enabled (i.e. it's not just measure noise). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 11:23:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 11:23:27 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary In-Reply-To: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> References: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> Message-ID: <064.daae756fc02e0d405f7fc6e9103b488c@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch Comment: MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/131 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 11:49:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 11:49:25 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI In-Reply-To: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> References: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> Message-ID: <064.09a8c3f45cf2dcef03c4478a4bb46205@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `heapprof001` also occasionally fails with the same panic ([https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_01_17/12575/17445/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190117T113941Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190117 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=383c0778b825e04099591919b5cb44dae3662cb42cd69b125cf3def62e142e10 example] from a `validate-x86_64-linux-fedora27` configuration): {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 134 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): heapprof001: internal error: LDV_recordDead: Failed to find counter for closure 0x42000af050 (GHC version 8.7.20190115 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug *** unexpected failure for heapprof001(prof_hc_hb)}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 12:44:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 12:44:27 -0000 Subject: [GHC] #16198: Cmm string literals shouldn't be represented as [Word8] Message-ID: <045.eab390ea1c7447194f424f58669324ce@haskell.org> #16198: Cmm string literals shouldn't be represented as [Word8] -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While we use ByteString to represent string literals in Core/STG, they are unpacked into [Word8] when compiled into Cmm. This is bad for performance, especially with large strings and there is no reason to do it. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 13:54:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 13:54:17 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.1e0f3e68e4ab3270ad0a268c0e9882db@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:15 simonpj]: > * `checkValidType` uses `check_type`, not `check_pred_ty`. I'm confused—didn't you say (in comment:3) that `checkValidType` should use `check_pred_ty` for `Constraint`-kinded things? (Now that I think about it, this is exactly why these errors are popping up—VTA simply didn't go down the `check_pred_ty` path before.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:00:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:00:58 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.16bcd8a42c376f82980b51fb5a788639@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: Added the test in https://gitlab.haskell.org/ghc/ghc/merge_requests/132 We should probably merge these commits to 8.8 branch if they're not merged already. Ben, updating status to "merge", please close the ticket if the commits on comment:5 are already merged. (I don't know where the 8.8 branch is so I can't check) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:01:10 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:01:10 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.743afbdabcc63ba813bbd3c49135b65d@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:28:53 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:28:53 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.f57ea396c6c2502f62d442092b33b784@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15799 Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This looks like it will be fixed by #16185. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:29:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:29:23 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.68f058b1c774ed22ca3426b228f34680@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Comment (by goldfire): Does this fix #15799? I bet it will. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:37:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:37:05 -0000 Subject: [GHC] #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release Message-ID: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14678 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6 claims to be bundled with `transformers-0.5.5.0`, but this isn't true. That's because it's using transformers commit ​https://gitlab.haskell.org/ghc/packages/transformers/tree/80557845cdc0e72bc05cec19cf7a1bf5495e9e69, which happened //after// the commit corresponding to the Hackage release of 0.5.5.0 (https://gitlab.haskell.org/ghc/packages/transformers/commit/33b3c8a71778ae37040088dfe022c648373777a8). This is not the first time this has happened: see #14678. While we were able to catch #14678 before a major release was shipped, but unfortunately, that didn't happen this time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:48:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:48:39 -0000 Subject: [GHC] #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.e0bd883f0e8e81c2bbf2017c76748e52@haskell.org> #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `process-1.6.3.0` is also affected: * The commit shipped with GHC 8.6 is https://gitlab.haskell.org/ghc/packages/process/commit/d14614572cc80bee734d49828b18a4f249e70199 * The Hackage commit for `1.6.3.0` is https://gitlab.haskell.org/ghc/packages/process/commit/7c0b58141290b50a338bf391adc0a8c43513165b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 14:51:35 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 14:51:35 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases (was: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release) In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.d5f9a06e4cb1f47283e3357b209ad839@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 15:12:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 15:12:11 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.4660cf9c0469e8a9ceb07ae37ea3d07a@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): gidyn, can you provide more details? Which GHC version are you using? How can I reproduce this? Are you sure that the program you are running isn't just running out of memory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 15:39:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 15:39:51 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.32a5dc44871181458f72c71fe62fc04a@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sigh, this is quite bad. We really need to rule this sort of thing out systematically from the release process. I'll work on this. In the meantime I have bumped `process` to 1.6.3.0 and `transformers` to 0.5.5.0 on `ghc-8.6`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 15:48:06 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 15:48:06 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.a8b00b2360213d74bb956d479f204912@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We should be careful about `transformers`, since there are actually API- relevant code changes that were introduced in commit https://gitlab.haskell.org/ghc/packages/transformers/commit/80557845cdc0e72bc05cec19cf7a1bf5495e9e69. In particular, I'm pretty sure that `contravariant-1.5` requires these changes to compile (at least, angerman reported an error when he tried to build `contravariant-1.5` with the Hackage version of `transformers-0.5.5.0`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 15:48:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 15:48:14 -0000 Subject: [GHC] #16200: Mechanical checking of submodule versions for releases Message-ID: <046.85ed747546987ad4f162b9df7cc7ffce@haskell.org> #16200: Mechanical checking of submodule versions for releases -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the past there have been a few cases where we have put out GHC releases which have shipped with submodule versions which do not correspond with a released package version (e.g. #16199). This should never happen. In principle the output of `git submodule` should be checked before a release is cut to ensure that all submodules point to tags. However, in practice this has proved to be insufficient due to two sources of false-positives: 1. our old mirroring infrastructure often failed to pick up tags 2. often we get away with a mere Hackage revision, which typically aren't tagged Thankfully (1) should no longer be a problem with the move to GitLab. Moreover, now since we finally have reliable CI we can automate release creation. However, it's not entirely clear how to reliably verify the consistency of submodules in light of problem (2). Unfortunately, it's quite tricky to avoid due to the existence of -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 15:48:30 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 15:48:30 -0000 Subject: [GHC] #16200: Mechanical checking of submodule versions for releases In-Reply-To: <046.85ed747546987ad4f162b9df7cc7ffce@haskell.org> References: <046.85ed747546987ad4f162b9df7cc7ffce@haskell.org> Message-ID: <061.46ca7d2cac773045a7505433248307c1@haskell.org> #16200: Mechanical checking of submodule versions for releases -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > In the past there have been a few cases where we have put out GHC > releases which have shipped with submodule versions which do not > correspond with a released package version (e.g. #16199). > > This should never happen. In principle the output of `git submodule` > should be checked before a release is cut to ensure that all submodules > point to tags. However, in practice this has proved to be insufficient > due to two sources of false-positives: > > 1. our old mirroring infrastructure often failed to pick up tags > 2. often we get away with a mere Hackage revision, which typically > aren't tagged > > Thankfully (1) should no longer be a problem with the move to GitLab. > Moreover, now since we finally have reliable CI we can automate release > creation. However, it's not entirely clear how to reliably verify the > consistency of submodules in light of problem (2). > > Unfortunately, it's quite tricky to avoid due to the existence of New description: In the past there have been a few cases where we have put out GHC releases which have shipped with submodule versions which do not correspond with a released package version (e.g. #16199). This should never happen. In principle the output of `git submodule` should be checked before a release is cut to ensure that all submodules point to tags. However, in practice this has proved to be insufficient due to two sources of false-positives: 1. our old mirroring infrastructure often failed to pick up tags 2. often we get away with a mere Hackage revision, which typically aren't tagged Thankfully (1) should no longer be a problem with the move to GitLab. Moreover, now since we finally have reliable CI we can automate release creation. However, it's not entirely clear how to reliably verify the consistency of submodules in light of problem (2). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 16:05:00 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 16:05:00 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.fd5c66dd8d98677506227831daba0e28@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gidyn): GHC 8.6.3 with https://bitbucket.org/accursoft/haskell-cloud/src. `cabal update` was killed by the OOM reaper. Running in a local image didn't commit an excessive amount of memory, but reserved 1 Tb virtual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 16:14:47 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 16:14:47 -0000 Subject: [GHC] #16200: Mechanical checking of submodule versions for releases In-Reply-To: <046.85ed747546987ad4f162b9df7cc7ffce@haskell.org> References: <046.85ed747546987ad4f162b9df7cc7ffce@haskell.org> Message-ID: <061.43fe0b87170b421cc1caf65f93c2c3bd@haskell.org> #16200: Mechanical checking of submodule versions for releases -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Started this in https://gitlab.haskell.org/ghc/ghc/merge_requests/133. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 16:33:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 16:33:54 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.b245be1c9549b44d9ca3c5afaddf16ea@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm confused—didn't you say (in comment:3) that checkValidType should use check_pred_ty for Constraint-kinded things? Yes I did, but that's not what has been implemented! Nor should it be, I think. comment:12 (at the top) says exactly when `check_pred_ty` is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 16:43:46 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 16:43:46 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.715387094956e6896bee1d1f11d35fc3@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > Current state is at: > https://gitlab.haskell.org/ghc/ghc/merge_requests/128 > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > * Add an `AnonArgFlag` to data constructor `Anon` in `TyCoRep` > {{{ > data TyCoBinder > = Named TyCoVarBinder -- A type-lambda binder > | Anon AnonArgFlag Type -- A term-lambda binder. Type here can be > CoercionTy. > -- Visibility is determined by the AnonArgFlag > }}} > and to data constructor `AnonTCB` (in `TyCon`) > {{{ > data TyConBndrVis > = NamedTCB ArgFlag > | AnonTCB AnonArgFlag > }}} > The latter is needed because the promoted version of a GADT data > constructor is a TyCon with some invisible (equality) arguments. > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always > `VisArg`. > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. We make a similar somewhat- > arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a > `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. Current state is at: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} * Add an `AnonArgFlag` to data constructor `Anon` in `TyCoRep` {{{ data TyCoBinder = Named TyCoVarBinder -- A type-lambda binder | Anon AnonArgFlag Type -- A term-lambda binder. Type here can be CoercionTy. -- Visibility is determined by the AnonArgFlag }}} and to data constructor `AnonTCB` (in `TyCon`) {{{ data TyConBndrVis = NamedTCB ArgFlag | AnonTCB AnonArgFlag }}} The latter is needed because the promoted version of a GADT data constructor is a TyCon with some invisible (equality) arguments. Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. We make a similar somewhat- arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. This is also the reason that `FunCo` does not have an `ArgFlag`; coercions only matter in Core, and are not shown to the user. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 16:44:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 16:44:54 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.6a2725c0f2b8ba3588d1afe7fc80112a@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > In Trac #15952 Richard and I agreed that it makes sense to add a flag to > `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. > > Current state is at: > https://gitlab.haskell.org/ghc/ghc/merge_requests/128 > > See [ticket:15952#comment:7] and [ticket:15952#comment:8]. > > Main changes: > > * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` > {{{ > data AnonArgFlag > = VisArg -- Used for (->): an ordinary non-dependent arrow > -- The argument is visible in source code > | InvisArg -- Used for (=>): a non-dependent predicate arrow > -- The argument is invisible in source code > }}} > > * `Type` looks like this > {{{ > data Type > = ... > > | FFunTy -- ^ t1 -> t2 Very common, so an important special case > -- FFunTy for "full function type"; see pattern synonym > for FunTy > { ft_af :: AnonArgFlag -- Is this (->) or (=>)? > , ft_arg :: Type -- Argument type > , ft_res :: Type } -- Resuult type > }}} > I'm using a record here to anticipate Linear Haskell, which will add a > multiplicity field to `FFunTy`. > > * Add a uni-directional pattern synonym for the old `FunTy` > {{{ > pattern FunTy :: Type -> Type -> Type > pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } > }}} > > * Add an `AnonArgFlag` to data constructor `Anon` in `TyCoRep` > {{{ > data TyCoBinder > = Named TyCoVarBinder -- A type-lambda binder > | Anon AnonArgFlag Type -- A term-lambda binder. Type here can be > CoercionTy. > -- Visibility is determined by the AnonArgFlag > }}} > and to data constructor `AnonTCB` (in `TyCon`) > {{{ > data TyConBndrVis > = NamedTCB ArgFlag > | AnonTCB AnonArgFlag > }}} > The latter is needed because the promoted version of a GADT data > constructor is a TyCon with some invisible (equality) arguments. > > Everything else follows routinely. > > A huge win is that `isPredTy` vanishes almost completely. > ------------------ > > Invariant: in `FFunTy af arg res` > * If `af` = `InvisArg` then `arg :: Constraint` > * But not vice versa > > When in Core-land, e.g. in the Simplifier, we often call `exprType`. > What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type > variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always > `VisArg`. > > For Core, it really doesn't matter; the `AnonArgFlag` only affects the > typing of source code. And it is quite painful to call `isPredTy` to see > if the arg type is `Constraint` when the answer doesn't matter. Plus, in > Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to > do anyway. > > We could try record the `AnonArgFlag` in the `Id`; but that means we'd > need to call `isPredTy` for every `Id` we construct. > > So for now I propose the above invariant. We make a similar somewhat- > arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a > `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. > > This is also the reason that `FunCo` does not have an `ArgFlag`; > coercions only matter in Core, and are not shown to the user. New description: In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. Current state is at: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} I'm using a record here to anticipate Linear Haskell, which will add a multiplicity field to `FFunTy`. * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} * Add an `AnonArgFlag` to data constructor `Anon` in `TyCoRep` {{{ data TyCoBinder = Named TyCoVarBinder -- A type-lambda binder | Anon AnonArgFlag Type -- A term-lambda binder. Type here can be CoercionTy. -- Visibility is determined by the AnonArgFlag }}} and to data constructor `AnonTCB` (in `TyCon`) {{{ data TyConBndrVis = NamedTCB ArgFlag | AnonTCB AnonArgFlag }}} The latter is needed because the promoted version of a GADT data constructor is a TyCon with some invisible (equality) arguments. Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. ------------------ Invariant: in `FFunTy af arg res` * If `af` = `InvisArg` then `arg :: Constraint` * But not vice versa When in Core-land, e.g. in the Simplifier, we often call `exprType`. What is the type of `Lam b e`? Either a `ForAllTy` (if `b` is a type variable) or a `FFunTy`. But what `AnonArgFlag`? I propose always `VisArg`. For Core, it really doesn't matter; the `AnonArgFlag` only affects the typing of source code. And it is quite painful to call `isPredTy` to see if the arg type is `Constraint` when the answer doesn't matter. Plus, in Core, `Type` and `Constraint` coincide, so it seems like a dodgy thing to do anyway. We could try record the `AnonArgFlag` in the `Id`; but that means we'd need to call `isPredTy` for every `Id` we construct. So for now I propose the above invariant. We make a similar somewhat- arbitrary choice for the `ArgFlag` in the `TyCoVarBinder` of a `ForAllTy`: in `exprType (Lam tv b)` we always use `Inferred`. This is also the reason that `FunCo` does not have an `ArgFlag`; coercions only matter in Core, and are not shown to the user. This does mean that `coercionKind co` might not have `InvisArg` where you expect; but that's the same problem as with `exprType`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:46:37 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:46:37 -0000 Subject: [GHC] #16198: Cmm string literals shouldn't be represented as [Word8] In-Reply-To: <045.eab390ea1c7447194f424f58669324ce@haskell.org> References: <045.eab390ea1c7447194f424f58669324ce@haskell.org> Message-ID: <060.c0694bd2fc2dc80af03be1ce86cb1c0c@haskell.org> #16198: Cmm string literals shouldn't be represented as [Word8] -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch Comment: Merge request: https://gitlab.haskell.org/ghc/ghc/merge_requests/135 Reusing the benchmark in #16190 (time to compile a file printing a string literal of the given size), I obtain the following results before and after the patch: || Size || Before patch || After patch || Gain || || 128 || 0.730 || 0.732 || 0% || || 3K || 0.731 || 0.727 || 0% || || 30K || 0.736 || 0.714 || +3% || || 100K || 0.804 || 0.748 || +7% || || 500K || 1.038 || 0.974 || +6% || || 1M || 1.342 || 1.157 || +14% || || 2M || 1.926 || 1.689 || +12% || || 3M || 2.539 || 2.088 || +18% || || 30M || 20.182 || 14.729 || +27% || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.81aeba428581e4f63b826bf242b00f61@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"74cd4ec5d2f9321aad5db3285cb60d78f2562996/ghc" 74cd4ec5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74cd4ec5d2f9321aad5db3285cb60d78f2562996" Fix raiseAsync() UNDERFLOW_FRAME handling in profiling runtime UNDERFLOW_FRAMEs don't have profiling headers so we have to use the AP_STACK's function's CCS as the new frame's CCS. Fixes one of the many bugs caught by concprog001 (#15508). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.32b0eae2bab6938e2b38f199b43fdc57@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"19670bc397d858b04eb9b4eb01480f7f8c59e2f5/ghc" 19670bc3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19670bc397d858b04eb9b4eb01480f7f8c59e2f5" Fix negative mutator time in GC stats in prof builds Because garbage collector calls `retainerProfile()` and `heapCensus()`, GC times normally include some of PROF times too. To fix this we have these lines: // heapCensus() is called by the GC, so RP and HC time are // included in the GC stats. We therefore subtract them to // obtain the actual GC cpu time. stats.gc_cpu_ns -= prof_cpu; stats.gc_elapsed_ns -= prof_elapsed; These variables are later used for calculating GC time excluding the final GC (which should be attributed to EXIT). exit_gc_elapsed = stats.gc_elapsed_ns - start_exit_gc_elapsed; The problem is if we subtract PROF times from `gc_elapsed_ns` and then subtract `start_exit_gc_elapsed` from the result, we end up subtracting PROF times twice, because `start_exit_gc_elapsed` also includes PROF times. We now subtract PROF times from GC after the calculations for EXIT and MUT times. The existing assertion that checks INIT + MUT + GC + EXIT = TOTAL now holds. When we subtract PROF numbers from GC, and a new assertion INIT + MUT + GC + PROF + EXIT = TOTAL also holds. Fixes #15897. New assertions added in this commit also revealed #16102, which is also fixed by this commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.4e824920b07cb0d15843c7dc6bf93c91@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"19670bc397d858b04eb9b4eb01480f7f8c59e2f5/ghc" 19670bc3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19670bc397d858b04eb9b4eb01480f7f8c59e2f5" Fix negative mutator time in GC stats in prof builds Because garbage collector calls `retainerProfile()` and `heapCensus()`, GC times normally include some of PROF times too. To fix this we have these lines: // heapCensus() is called by the GC, so RP and HC time are // included in the GC stats. We therefore subtract them to // obtain the actual GC cpu time. stats.gc_cpu_ns -= prof_cpu; stats.gc_elapsed_ns -= prof_elapsed; These variables are later used for calculating GC time excluding the final GC (which should be attributed to EXIT). exit_gc_elapsed = stats.gc_elapsed_ns - start_exit_gc_elapsed; The problem is if we subtract PROF times from `gc_elapsed_ns` and then subtract `start_exit_gc_elapsed` from the result, we end up subtracting PROF times twice, because `start_exit_gc_elapsed` also includes PROF times. We now subtract PROF times from GC after the calculations for EXIT and MUT times. The existing assertion that checks INIT + MUT + GC + EXIT = TOTAL now holds. When we subtract PROF numbers from GC, and a new assertion INIT + MUT + GC + PROF + EXIT = TOTAL also holds. Fixes #15897. New assertions added in this commit also revealed #16102, which is also fixed by this commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.0db0b6032e9d47fb8fa0f759de2c7223@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11606 Blocked By: | Blocking: Related Tickets: #16096 | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a34ee61545930d569d0dbafb3a4a5db3a7a711e5/ghc" a34ee615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a34ee61545930d569d0dbafb3a4a5db3a7a711e5" Refactor GHCi UI to fix #11606, #12091, #15721, #16096 Instead of parsing and executing a statement or declaration directly we now parse them first and then execute in a separate step. This gives us the flexibility to inspect the parsed declaration before execution. Using this we now inspect parsed declarations, and if it's a single declaration of form `x = y` we execute it as `let x = y` instead, fixing a ton of problems caused by poor declaration support in GHCi. To avoid any users of the modules I left `execStmt` and `runDecls` unchanged and added `execStmt'` and `runDecls'` which work on parsed statements/declarations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.fbe74d3a897736874cecc6f40274df8a@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR:97 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a34ee61545930d569d0dbafb3a4a5db3a7a711e5/ghc" a34ee615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a34ee61545930d569d0dbafb3a4a5db3a7a711e5" Refactor GHCi UI to fix #11606, #12091, #15721, #16096 Instead of parsing and executing a statement or declaration directly we now parse them first and then execute in a separate step. This gives us the flexibility to inspect the parsed declaration before execution. Using this we now inspect parsed declarations, and if it's a single declaration of form `x = y` we execute it as `let x = y` instead, fixing a ton of problems caused by poor declaration support in GHCi. To avoid any users of the modules I left `execStmt` and `runDecls` unchanged and added `execStmt'` and `runDecls'` which work on parsed statements/declarations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.adb99ab66d3417ddc20e184cb151669b@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b12b3f0240321ac1ee43f14eb9c07e015022eeb/ghc" 7b12b3f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b12b3f0240321ac1ee43f14eb9c07e015022eeb" itimer: Don't free condvar until we know ticker is stopped When we are shutting down the pthread ticker we signal the start_cond condition variable to ensure that the ticker thread wakes up and exits in a reasonable amount of time. Previously, when the ticker thread would shut down it was responsible for freeing the start_cond condition variable. However, this would lead to a race wherein the ticker would free start_cond, then the main thread would try to signal it in an effort to wake the ticker (#16150). Avoid this by moving the mutex destruction to the main thread. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.a3dd5e50f79ecbaa6e5f77e7d00c6152@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T16059{a,c,d,e} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/112 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9dc56b61ae10cb26ec8b2bc132ae6c9b620707a8/ghc" 9dc56b6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9dc56b61ae10cb26ec8b2bc132ae6c9b620707a8" Control validity-checking of type synonym applications more carefully Trac #16059 shows that when validity checking applications of type synonyms, GHC sometimes wasn't checking the expanded type enough. We must be careful, however, since checking both the expanded type as well as the arguments to the type synonym can lead to exponential blowup (see https://ghc.haskell.org/trac/ghc/ticket/16059#comment:4). Nor can we omit checking either the expanded type or the argument for correctness reasons. The solution here is to introduce a new `ExpandMode` data type that is plumbed through all of the type-validity-checking functions in `TcValidity`. `ExpandMode` dictates whether we only check the expanded type (`Expand`), only check the arguments (`NoExpand), or both (`Both`). Importantly, if we check `Both` in the function for validity checking type synonym applications, then we switch to `NoExpand` when checking the arguments so as to avoid exponential blowup. See `Note [Correctness and performance of type synonym validity checking]` for the full story. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.128d24d2258380462f92a181f3a724da@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ce11f6f25c1160262830d9670c4eaaebac37cbaf/ghc" ce11f6f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce11f6f25c1160262830d9670c4eaaebac37cbaf" rts: Use always-available locking operations in pthread Itimer implementation Previously we ACQUIRE_LOCK and RELEASE_LOCK but these compile to a noop in the non-threaded RTS, as noted in #16150. Use OS_ACQUIRE_LOCK and OS_RELEASE_LOCK instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.283cde53fe02e7ff202719472a7491dd@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f65025eeb4a79458af26d759e932d70633a64db/ghc" 2f65025e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f65025eeb4a79458af26d759e932d70633a64db" Hadrian: support extra libraries + OSX rpath Summary: This fixes some of the issues that surfaced when trying to build dynamic GHC on OSX. Unfortunately, due some other `libffi` issues, this doesn't completely fix dynamic builds on OSX. - Use 'extra-libraries' from .cabal files instead of hardcoding which packages need which extra libs. Also add support for 'extra-lib-dirs'. - Make sure Hadrian looks in the right places to support both plain '.buildinfo' and '.buildinfo.in' files. - Make the '-rpath' support more robust across OS's (it previously didn't work on OSX and possibly windows either). Reviewers: angerman, alpmestan, adamse, DavidEichmann, bgamari, Phyx Subscribers: rwbarton, carter GHC Trac Issues: #15990 Differential Revision: https://phabricator.haskell.org/D5409 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.42da0736b482a4a21b85e9350575a8d3@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 35 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9fb744bdc54c75cf5b91aa783b18233ba8da04a6/ghc" 9fb744b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9fb744bdc54c75cf5b91aa783b18233ba8da04a6" GHCi ignores cmd line flags XMonomorphismRestr.. XNoExtendedDef..#10857 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.4f5e48de08dce71a979fba7c678d4883@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T16114 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/92 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"83a22066fbe136e4a984e8c90c1d3fd72b6ec4b9/ghc" 83a22066/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83a22066fbe136e4a984e8c90c1d3fd72b6ec4b9" Fix #16114 by adding a validity check to rnClsInstDecl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.4e75cf93b7e52f1a03643c8ebc7c0f31@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"236abdb80ab894b093faca7911ad8cabd6dc3e81/ghc" 236abdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="236abdb80ab894b093faca7911ad8cabd6dc3e81" rts: Allow heap prof by closure type in prof way Complete b7b6617a90824303daf555c817f538cd9c792671 (see ticket #15086) to actually enable profiling by closure type in the profiling rts. I.e. +RTS -p -hT is now accepted. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.cdd6884dc7b5d06e7aa48e2a47bc5b74@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 35 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f78048f6575b370f078bcddc6b9e64bfe23932eb/ghc" f78048f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f78048f6575b370f078bcddc6b9e64bfe23932eb" Change comments as requested by code review. #10857 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables In-Reply-To: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> References: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> Message-ID: <065.a235d463ea53e8036e374c7c48e89bd7@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T16116a, | rename/should_fail/T16116b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/110 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"e63518f5d6a93be111f9108c0990a1162f88d615/ghc" e63518f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e63518f5d6a93be111f9108c0990a1162f88d615" Fix #16116 by removing badAssocRhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian In-Reply-To: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> Message-ID: <065.b3b59674f28ebc45341b75b84e9c2e3b@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/107 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2e05912086bbb8eab213d44af300ecc396d912aa/ghc" 2e05912/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e05912086bbb8eab213d44af300ecc396d912aa" Hadrian: handle Haddock's resource directory Fixes #16105 * Require Haddock's resource as runtime dependencies of the Haddock builder. This means we no longer have to `need` particular resources in every other documentation rule. * Do a _tracked_ copy of both the 'html' and 'latex' folder resource folders. * Move resources into `stage1/lib` (NB: the `haddock` binary goes in `stage1/bin`). Besides now actually matching the Haddock script wrapper generated by BinaryDist, this also prepares for Haddock in relocatable build folder detecting its own resources. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.b3288adb4c4ac92711e7e91c64a5f991@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T16096 Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a34ee61545930d569d0dbafb3a4a5db3a7a711e5/ghc" a34ee615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a34ee61545930d569d0dbafb3a4a5db3a7a711e5" Refactor GHCi UI to fix #11606, #12091, #15721, #16096 Instead of parsing and executing a statement or declaration directly we now parse them first and then execute in a separate step. This gives us the flexibility to inspect the parsed declaration before execution. Using this we now inspect parsed declarations, and if it's a single declaration of form `x = y` we execute it as `let x = y` instead, fixing a ton of problems caused by poor declaration support in GHCi. To avoid any users of the modules I left `execStmt` and `runDecls` unchanged and added `execStmt'` and `runDecls'` which work on parsed statements/declarations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:47:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:47:05 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.e4e48b1ef36c149eaf6eb45b09ef93ba@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a34ee61545930d569d0dbafb3a4a5db3a7a711e5/ghc" a34ee615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a34ee61545930d569d0dbafb3a4a5db3a7a711e5" Refactor GHCi UI to fix #11606, #12091, #15721, #16096 Instead of parsing and executing a statement or declaration directly we now parse them first and then execute in a separate step. This gives us the flexibility to inspect the parsed declaration before execution. Using this we now inspect parsed declarations, and if it's a single declaration of form `x = y` we execute it as `let x = y` instead, fixing a ton of problems caused by poor declaration support in GHCi. To avoid any users of the modules I left `execStmt` and `runDecls` unchanged and added `execStmt'` and `runDecls'` which work on parsed statements/declarations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 17:48:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 17:48:41 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.d89cfa984d0addef88195015f23993fa@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a1e9cd6af8b41fa451fd3be806f4aced0040a14c/ghc" a1e9cd6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a1e9cd6af8b41fa451fd3be806f4aced0040a14c" Add test for #16197 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:03:22 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:03:22 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian In-Reply-To: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> Message-ID: <065.f4a59b5e43e707b8135d5df9b6bcb49e@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/107 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:04:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:04:12 -0000 Subject: [GHC] #15982: Hadrian's `--configure` flag is broken on Windows In-Reply-To: <050.1db3a576777b406081d2912367d7ba45@haskell.org> References: <050.1db3a576777b406081d2912367d7ba45@haskell.org> Message-ID: <065.be15c580558f27d3358b2b5d37cae209@haskell.org> #15982: Hadrian's `--configure` flag is broken on Windows -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged with 8d594beff68a6b12cdc8ccbd0cfc3e11cf184bfc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:06:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:06:05 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.3255123c7086e9dd63b828c2b68d6f8f@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Relevant commit: 7218270dee1067db9c4f342b97e07ca89b80b82d. snowleopard, please do format ticket references as `#15971` instead of a URL. This ensures that cross-referencing Trac comments are generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:07:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:07:11 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.e8d7c5a650c9334acf4621678c093e75@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): d2eb344a38f6c727040ba76e584aeaca8e8aefb3 went a long ways towards fixing the remaining issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:08:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:08:15 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.e937b98c543f40145ba2ba949e9cec23@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 35 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Fixed in #10857. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:13:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:13:27 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.eb7eae50acdb30e22a2b574720354419@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe this should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:16:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:16:07 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.bca8724ea98f7c1c81198d4faa49d228@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Wait, when did this get fully fixed? Weren't there still some outstanding `libffi` issues? My patch was definitely //not// enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:26:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:26:11 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.b37eb8a9992b56ae6186adc603d5f8b6@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Alright, in that case my belief was incorrect :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:27:56 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:27:56 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.c55176a1456578f4489237f70a5bfbb0@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): My apologies, I didn't realize that you were implying that we should no longer implement the suggestion in comment:3. But calling `check_pred_ty` (instead of `check_ty`) from `checkValidType` is the only reason that the original program in this ticket is accepted! If you don't do that, then we're right back where we started: {{{ ../Bug.hs:7:1: error: • Illegal polymorphic type: forall a. Eq (f a) GHC doesn't yet support impredicative polymorphism • In the expansion of type synonym ‘F1’ In the type synonym declaration for ‘F2’ | 7 | type F2 f = (Functor f, F1 f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The problem is that for type synonym RHSes, we call both `checkValidType` and `checkTySynRHS` on them (in [https://gitlab.haskell.org/ghc/ghc/blob/a1e9cd6af8b41fa451fd3be806f4aced0040a14c/compiler/typecheck/TcTyClsDecls.hs#L2854-2856 this code]): {{{#!hs | Just syn_rhs <- synTyConRhs_maybe tc -> do { checkValidType syn_ctxt syn_rhs ; checkTySynRhs syn_ctxt syn_rhs } }}} As a result, we end up calling both `check_type` and `check_pred` on `(Functor f, F1 f)`, and `check_type` ends up rejecting it for being "impredicative". Do you think we'd be better off not calling `checkValidType` here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:28:53 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:28:53 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.3b69f04fdfe921b86e4ea63176af77eb@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.8.1 Comment: I'm just going to bump the `ghc-8.8` branch to match `master` as of today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:29:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:29:14 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.47bfbeee561d23b654cf4b34d0dd3772@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.4 Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:29:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:29:42 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.f0a84f47171ff0fed817d9ae1770750f@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.4 Comment: I'm very happy to have this fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 18:54:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 18:54:31 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin Message-ID: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> #16201: ghci063 failing on Darwin ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{#!diff --- /dev/null 2019-01-16 12:17:41.000000000 -0800 +++ ghci/scripts/ghci063.run/ghci063.run.stderr.normalised 2019-01-16 12:17:42.000000000 -0800 @@ -0,0 +1,2 @@ + +B.hs:1:1: parse error on input ‘***’ }}} The test in question is just a normal `ghci_script` test: {{{ :! echo module A where {} >A.hs :! echo module B where { import A } >B.hs :load B -- We're going to replace B.hs with an invalid module but without -- changing its timestamp. A :reload should *not* look at the -- contents of the file, because the timestamp hasn't changed. :! cp B.hs B.hs-copy :! touch -r B.hs B.hs-copy :! echo "*** INVALID ***" >B.hs :! touch -r B.hs-copy B.hs :reload -- Put the original file back, now it should work :! cp B.hs-copy B.hs :reload }}} I have no idea why GHCi would be trying to parse the `!echo`, much less only on Darwin. This is currently the last issue Darwin issue keeping us from setting `allow_failure` to false so I'm going to mark this as broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 21:47:19 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 21:47:19 -0000 Subject: [GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base` In-Reply-To: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> References: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> Message-ID: <062.bb74771450868a555e2c1085fb494ad0@haskell.org> #16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: base, | profunctor, QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 22:01:59 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 22:01:59 -0000 Subject: [GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base` In-Reply-To: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> References: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> Message-ID: <062.94cf29677912b3c78406e0a912db4458@haskell.org> #16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: base, | profunctor, QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): This is something likely to be brought up in the [https://mail.haskell.org /cgi-bin/mailman/listinfo/libraries library mailing list] simultaneously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 22:12:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 22:12:04 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.d01b40c9ec2f6a77b4f3ddb71bbbd133@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Trying the GitLab repo has allowed the `validate --slow` to complete {{{ ==== STAGE 1 TESTS ==== SUMMARY for test run started at Thu Jan 17 22:05:37 2019 GMT 0:00:04 spent to go through 2 total tests, which gave rise to 8 test cases, of which 0 were skipped 0 had missing libraries 8 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="ArithInt16 ArithWord16 CPUTime001 Overflow T11334b T14740 T14761c T2783 T3816 T5515 hpc_fork process005 recomp007 static-plugins tcfail159 user001" SUMMARY for test run started at Thu Jan 17 20:52:24 2019 GMT 1:13:11 spent to go through 6794 total tests, which gave rise to 26417 test cases, of which 4911 were skipped 233 had missing libraries 21015 expected passes 224 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 33 unexpected failures 0 unexpected stat failures Unexpected passes: /tmp/ghctest-pph4g991/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) Unexpected failures: /tmp/ghctest-pph4g991/test spaces/dependent/should_fail/T11334b.run T11334b [stderr mismatch] (normal) /tmp/ghctest-pph4g991/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-pph4g991/test spaces/indexed-types/should_fail/T5515.run T5515 [stderr mismatch] (normal) /tmp/ghctest-pph4g991/test spaces/parser/should_fail/T14740.run T14740 [stderr mismatch] (normal) /tmp/ghctest-pph4g991/test spaces/plugins/static-plugins.run static-plugins [bad stderr] (profasm) /tmp/ghctest-pph4g991/test spaces/plugins/static-plugins.run static-plugins [bad stderr] (profthreaded) /tmp/ghctest-pph4g991/test spaces/primops/should_run/ArithWord16.run ArithWord16 [bad stderr] (ghci) /tmp/ghctest-pph4g991/test spaces/primops/should_run/ArithInt16.run ArithInt16 [bad stderr] (ghci) /tmp/ghctest-pph4g991/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (hpc) /tmp/ghctest-pph4g991/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (optasm) /tmp/ghctest-pph4g991/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (profasm) /tmp/ghctest-pph4g991/test spaces/typecheck/should_fail/tcfail159.run tcfail159 [stderr mismatch] (normal) /tmp/ghctest-pph4g991/test spaces/warnings/should_compile/Overflow.run Overflow [stderr mismatch] (hpc) /tmp/ghctest-pph4g991/test spaces/libraries/base/tests/CPUTime001.run CPUTime001 [bad stdout] (threaded2) /tmp/ghctest-pph4g991/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-pph4g991/test spaces/libraries/process/tests/process005.run process005 [bad stderr] (ghci) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (hpc) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optasm) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profasm) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded1) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded2) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (dyn) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profthreaded) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (hpc) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optasm) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profasm) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (ghci) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded1) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded2) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (dyn) /tmp/ghctest-pph4g991/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20190117 Timestamp 2019-01-17 20:52:20.094812333 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20190117/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20190117/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20190117/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20190117/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20190117/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20190117/package.conf.d"] == End post-testsuite package check }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 22:30:26 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 22:30:26 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.c05ee26611c28a97d4b3046962f6eb55@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Do you think we'd be better off not calling checkValidType here? Yes! If we are going to have `checkTySynRhs` at all, then we should do all the work there. This is the commit that added `checkTySynRhs`. {{{ commit 35c9de7ca053eda472cb446c53bcd2007bfd8394 Author: Simon Peyton Jones Date: Sat Jun 11 23:56:42 2016 +0100 Move the constraint-kind validity check For type synonyms, we need to check that if the RHS has kind Constraint, then we have -XConstraintKinds. For some reason this was done in checkValidType, but it makes more sense to do it in checkValidTyCon. I can't remember quite why I made this change; maybe it fixes a Trac ticket, but if so I forget which. But it's a modest improvement anyway. }}} But calling both makes no sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 17 23:10:00 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Jan 2019 23:10:00 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.448a1205904641b50f9a7c3f24dc4f4a@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 00:13:46 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 00:13:46 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.077649531b0d3d9754760bfb7b6c9bbd@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Ben: Sure, will do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 01:23:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 01:23:58 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.0a2debe7e9e77d5c5cfebf1d85324f53@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): So I've come up with a plan which I think should work. I'll try to whip it up today and see how it performs. I'll need the produces artifacts anyway to get this resolved. For each of the (external) libraries, we'll run `cabal new-sdist` (1) Then we'll pull the same one from hackage with `cabal get --pristine`. (2) And finally run a diff over the unpacked one from (1) and (2). This should yield an empty set. I'll try using this approach to generate me the sufficient patches for the packages that are in ghc and for which hackage has different source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 01:42:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 01:42:06 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.c2f8267201abaa300d1ddb5097779b23@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"469fe6133646df5568c9486de2202124cb734242/ghc" 469fe61/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="469fe6133646df5568c9486de2202124cb734242" 'DynFlag'-free version of 'mkParserFlags' Summary: This is a fixed version of the reverted d2fbc33c4ff3074126ab71654af8bbf8a46e4e11 and 5aa29231ab7603537284eff5e4caff3a73dba6d2. Obtaining a `DynFlags` is difficult, making using the lexer/parser for pure parsing/lexing unreasonably difficult, even with `mkPStatePure`. This is despite the fact that we only really need * language extension flags * warning flags * a handful of boolean options The new `mkParserFlags'` function makes is easier to directly construct a `ParserFlags`. Furthermore, since `pExtsBitmap` is just a footgun, I've gone ahead and made `ParserFlags` an abstract type. Also, we now export `ExtBits` and `getBit` instead of defining/exporting a bunch of boilerplate functions that test for a particular 'ExtBits'. In the process, I also * cleaned up an unneeded special case for `ITstatic` * made `UsePosPrags` another variant of `ExtBits` * made the logic in `reservedSymsFM` match that of `reservedWordsFM` Test Plan: make test Reviewers: bgamari, alanz, tdammers Subscribers: sjakobi, tdammers, rwbarton, mpickering, carter GHC Trac Issues: #11301 Differential Revision: https://phabricator.haskell.org/D5405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:02:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:02:32 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.04d8e5bc6eefdb55c5eec9ee9540bb4c@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Alright, here we are (for ghc-8.6.3-release) {{{ -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 Win32-2.6.1.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 array-0.5.3.0.patch -rw-r--r-- 1 angerman staff 642B Jan 18 10:00 binary-0.8.6.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 bytestring-0.10.8.2.patch -rw-r--r-- 1 angerman staff 70B Jan 18 10:00 containers-0.6.0.1.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 deepseq-1.4.4.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 directory-1.3.3.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 filepath-1.4.2.1.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 haskeline-0.7.4.3.patch -rw-r--r-- 1 angerman staff 675B Jan 18 10:00 hpc-0.6.0.3.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 mtl-2.2.2.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 parallel-3.2.2.0.patch -rw-r--r-- 1 angerman staff 1.4K Jan 18 10:00 parsec-3.1.13.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 pretty-1.1.3.6.patch -rw-r--r-- 1 angerman staff 6.0K Jan 18 10:00 process-1.6.3.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 stm-2.5.0.0.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 terminfo-0.4.1.2.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 text-1.2.3.1.patch -rw-r--r-- 1 angerman staff 5.4K Jan 18 10:00 time-1.8.0.2.patch -rw-r--r-- 1 angerman staff 20K Jan 18 10:00 transformers-0.5.5.0.patch -rw-r--r-- 1 angerman staff 4.8K Jan 18 10:00 unix-2.7.2.2.patch -rw-r--r-- 1 angerman staff 0B Jan 18 10:00 xhtml-3000.2.2.1.patch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:03:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:03:13 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.a1d0ea17bc7e15efc626c4e68312d407@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * Attachment "verify-packages.sh" added. verify-packages.sh -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:04:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:04:10 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.cc3f412a1664a1eef87409a861b758f3@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): The verify-packages.sh will generate the cabal sdists, pull the corresponding package from hackage, and diff them. Giving you the output above in the end. Ideally they should all be 0B in size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:27:09 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:27:09 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.69bcf47c726bca3a9941ef30433ed8ba@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -------------------------------------+------------------------------------- Changes (by angerman): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:28:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:28:23 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.fbc07abdc79535c3c86328c12d91b5fc@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): New approach: instead of messing with Core, we only add the optimization into the NCG. For large strings, instead of printing `.asciz "..."` we print `.incbin "tmpfileXXX.dat"` and we dump the contents of the string into "tmpfileXXX.dat". This relies on the patch for #16198 so that we benefit from ByteStrings for string literals down to the NCG. I have updated the branch: https://gitlab.haskell.org/hsyl20/ghc/tree/hsyl20-T16190 This new approach works very well even with TH generated string literals. The following table shows the time to compile a source that uses `file- embed` with different file sizes. I have set the threshold to 500k for the test and as the default value in the patch (hence the optimization is not triggered for the 4 first file sizes). || Size || 8.6.3 || HEAD + #16198 || HEAD + #16198 + Threshold 500K || Gain || || 128 || 2.650 || 2.331 || 2.346 || (-0.5%) || || 3K || 2.651 || 2.289 || 2.290 || (0%) || || 30K || 2.590 || 2.353 || 2.307 || (+2%) || || 100K || 2.717 || 2.379 || 2.389 || (0%) || || 500K || 3.621 || 2.814 || 2.331 || +17% || || 1M || 4.694 || 3.526 || 2.654 || +24% || || 2M || 6.784 || 4.668 || 2.650 || +21% || || 3M || 8.851 || 5.616 || 3.073 || +45% || || 30M || 63.181 || 34.318 || 8.517 || +75% || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 02:33:52 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 02:33:52 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.b5d940812ae9d4c446ffcfeb4135e478@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16190 | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * related: => #16190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 06:34:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 06:34:31 -0000 Subject: [GHC] #16042: T13031 doesn't get run In-Reply-To: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> References: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> Message-ID: <061.5d5423abcc413bbd8f30c2179ad11640@haskell.org> #16042: T13031 doesn't get run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): There's another problem in `test_common_work`: if I define a `run_command` test with `only_ways(['optasm'])` my test will never run, because `if func == ...` always sets `all_ways = ['normal']` when `func` is `run_command`. I wonder if we have any tests that never run because of this.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 08:08:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 08:08:03 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.d21e95cb1dbb8d5ee6edc5f71cbbda0f@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 angerman]: > For each of the (external) libraries, we'll run `cabal new-sdist` (1) > Then we'll pull the same one from hackage with `cabal get --pristine`. (2) > And finally run a diff over the unpacked one from (1) and (2). > > This should yield an empty set. Fwiw, we can't guarantee this in general, nor do we need to. There is no requirement that you can actually reinstall a boot package release bundled with GHC. There's no need for that, and there's packages that inevitably fall into this category. So tooling needs to be able to cope with that anyway; and in fact Cabal does. That being said, the only invariant that actually matters and the only one I care about very strongly is that of **consistent API versioning**: **If a package `foo-1.2.3` is bundled with GHC then if-and-only-if there is a valid build-plan (meeting all involved version constraints), then the `foo-1.2.3` from Hackage re-synthesized via Cabal must not to be distinguishable at the API level from the GHC pkg-db pre-installed one. In other words, `foo-1.2.3` shall uniquely determine the observable API exposed of that package.** A very prominent example was the `mtl` package that shipped with GHC 8.4.1 which broke the API versioning and caused real-world problems which (see https://github.com/haskell-hvr/HsYAML/issues/1 which required some very awkward CPP -- but in general this kind of problem is not always workaroundable by CPP! We ''must'' be able to trust the API versioning or we'd have to give up on version numbers altogether) Anything else, like diverging testsuites/benchmark components or other deltas which have no effect on the exposed API are of very little concern to me. Avoiding divergences would require enough time between the final release and the preceding release of a GHC last-beta or release-candidate after which boot package maintainers can be encouraged to publish their package release candidates on Hackage to the primary index (and I have to stress: "and no sooner!", as it's strongly discouraged to make releases on Hackage which target or advertise support for unreleased dependencies or tooling, or causing avoidable uploads to Hackage as is clearly specified in the Hackage upload guidelines), after we have ensured (in topological dep ordering) that the package candidates are sound and in sync with the artifacts included in the GHC release, and also fix any minor and not so minor issues detected in the process. or spelled out differently, the protocol for finalising boot libraries would be more or less like 1. release a last-beta/release-candidate 2. go over all boot libraries in topological sorted order and ensure their exposed API matched the Hackage release candidate; ensure that the compatibility advertised via version constraints is accurate; if needed, coordinate fixups with the maintainer 3. restart 2. in case there's not-so-minor changes which might cause an avalanche effect on their rev-deps 4. if there were fixups needed, make sure to `./validate` again; 5. when it's clear that the release-candidate has no more issues (otherwise go back to 1.) and we're going to cut the final release; encourage package maintainers to publish their latest Hackage package release candidate (which we verified to match the one contained in GHC's release) to the main index (i.e. press that "publish" button in the Hackage release candidate UI) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 08:46:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 08:46:42 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.dfd184e01c6b4039ca6755ae00887531@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds great! Before you are done, could you write a Note that gives a birds-eye view of all the moving parts involved in string literals, and point to it from appropriate places? Thanks for working so hard on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:08:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:08:07 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces Message-ID: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is to track part two of the plan here: https://gitlab.haskell.org/ghc/ghc/merge_requests/50#note_1808. When installing a bindist, the make system runs `ghc-cabal` to reconfigure packages and regenerate the package DB. Hadrian, on the other hand, seems to just be copying the package DB as is to its install location. This is mostly OK since most paths only need to be relative to package root. However, it breaks down for the `haddock-interfaces` and `haddock-html` fields, (esp. since documentation can be installed in a completely different location). The following interaction demonstrates the problem. Note how `ghc-pkg` is pointing us to a directory that doesn't even exist! {{{ $ ./hadrian/build.sh -c -j binary-dist $ mv _build/bindist/ghc-8.7.20190117-x86_64-apple-darwin.tar.xz /Users/alec/scratch $ cd /Users/alec/scratch $ tar xpvf ghc-8.7.20190117-x86_64-apple-darwin.tar.xz $ ./configure --prefix=/Users/alec/scratch && make install $ ./bin/ghc-pkg field base haddock-html haddock-html: /Users/alec/scratch/lib/../../docs/html/libraries/base $ ls /Users/alec/scratch/lib/../../docs/html/libraries/base ls: /Users/alec/scratch/lib/../../docs/html/libraries/base: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:08:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:08:10 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.aabb7d171752f5ff114ba0dd875c9f01@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Has any thought been given if and how this will interact with https://github.com/ghc-proposals/ghc-proposals/pull/135? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:12:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:12:30 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.cd4639f7b6dc4946d12e79ed7eaa235f@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: alpmestan, angerman (added) Comment: I'm really not sure what the best way is to fix this. Obviously we could bring `ghc-cabal` in, but that's a bit overkill. I lean towards manually patching the `.conf` files as part of the install script then running `ghc-pkg recache` at the end. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:41:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:41:21 -0000 Subject: [GHC] #16042: T13031 doesn't get run In-Reply-To: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> References: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> Message-ID: <061.493ff95acc3ca54b339eb15a5d5925d6@haskell.org> #16042: T13031 doesn't get run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:47:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:47:08 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.dae2ee8573408825c41203727dddb526@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:48:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:48:39 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.12795833730281e05d164773e9aba423@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:49:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:49:04 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.9d2d847f1b2244827fc7a36c23962a19@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: CPRAnalysis, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:49:50 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:49:50 -0000 Subject: [GHC] #6070: Fun with the demand analyser In-Reply-To: <046.c6530061559c47a83051d5bf2c366594@haskell.org> References: <046.c6530061559c47a83051d5bf2c366594@haskell.org> Message-ID: <061.05a831fd56a4e4ce4f41a5691a4d95f9@haskell.org> #6070: Fun with the demand analyser -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:50:00 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:50:00 -0000 Subject: [GHC] #5949: Demand analysis attributes manifestly wrong demand type In-Reply-To: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> References: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> Message-ID: <068.8984596a60e4f35cac85bd22b9f0a223@haskell.org> #5949: Demand analysis attributes manifestly wrong demand type -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:50:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:50:13 -0000 Subject: [GHC] #5775: Inconsistency in demand analysis In-Reply-To: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> References: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> Message-ID: <056.7ed0fa1521763a46fc682ce04b6bba88@haskell.org> #5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:50:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:50:25 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.11b2f3295b30038771bb1b9862db2e67@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------- Reporter: tibbe | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:51:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:51:03 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.0b6b82ed130556084fa51ce3f3f7431c@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: JoinPoints => JoinPoints, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:51:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:51:43 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.8e4b53115a64b7883a877d1885e0243b@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: JoinPoints => JoinPoints, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:51:59 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:51:59 -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.79cf0ffe3bdba772d9952575ef668711@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: SpecConstr, | CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: SpecConstr => SpecConstr, CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:52:55 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:52:55 -0000 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@haskell.org> References: <046.ecd79a44a24e66ebe8454442595b165e@haskell.org> Message-ID: <061.2177b5f9d225f79655ce4bca1c7bd0eb@haskell.org> #3138: Returning a known constructor: GHC generates terrible code for cmonad -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:54:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:54:15 -0000 Subject: [GHC] #1885: Improve CPR analysis In-Reply-To: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> References: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> Message-ID: <061.3796b65f33632d056e61d82d4199d798@haskell.org> #1885: Improve CPR analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: CPRAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:54:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:54:58 -0000 Subject: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics In-Reply-To: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> References: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> Message-ID: <058.c3bee3406c0d98b04a7065872c712161@haskell.org> #1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------------+------------------------------------- Reporter: neil | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cg059 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:56:55 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:56:55 -0000 Subject: [GHC] #4941: SpecConstr generates functions that do not use their arguments In-Reply-To: <046.96b4c779d798fee1961760fb67e6fe6f@haskell.org> References: <046.96b4c779d798fee1961760fb67e6fe6f@haskell.org> Message-ID: <061.46b1881757364bdfd3c930e33f77f948@haskell.org> #4941: SpecConstr generates functions that do not use their arguments -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.1 Resolution: | Keywords: SpecConstr, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: SpecConstr => SpecConstr, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:58:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:58:44 -0000 Subject: [GHC] #16197: Strictness is not preserved under -O1 In-Reply-To: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> References: <045.6889d125b7e88bf9c33d9a496f278f22@haskell.org> Message-ID: <060.38daf61bc0c9f920b06759cb549ca7c7@haskell.org> #16197: Strictness is not preserved under -O1 -------------------------------------+------------------------------------- Reporter: alang9 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:58:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:58:53 -0000 Subject: [GHC] #16029: Inadequate absence analysis In-Reply-To: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> References: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> Message-ID: <061.c5698934f5fc75f59dd9af55f4aa7a69@haskell.org> #16029: Inadequate absence analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T16029 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:59:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:59:20 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.177b95a4a32c154ab8c41738d661dd98@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 09:59:59 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 09:59:59 -0000 Subject: [GHC] #15627: Absent unlifted bindings In-Reply-To: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> References: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> Message-ID: <059.98cd4d7bb76d0afd598c38939f02aab9@haskell.org> #15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T15627 Blocked By: | Blocking: Related Tickets: #9279 #4328 | Differential Rev(s): Phab:D5153 #11126 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:00:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:00:41 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.ebe776b5bcf88c2d7ee7cdcdef869e33@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Exceptions, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Exceptions => Exceptions, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:05:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:05:53 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.eb306afef012056044396b587c840e2e@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:08:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:08:41 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.168e028a0c3e37a54b8b051c3c3c9414@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:09:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:09:27 -0000 Subject: [GHC] #14998: Sort out the strictness mess for exceptions In-Reply-To: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> References: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> Message-ID: <061.532c8445b0932b2043295723c5d6d44e@haskell.org> #14998: Sort out the strictness mess for exceptions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Exceptions, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11555 #13330 | Differential Rev(s): #10712 #11222 #13380 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Exceptions => Exceptions, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:14:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:14:20 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.1a7fcdbd8ef483482e92f6f2c1d387d6@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:15:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:15:11 -0000 Subject: [GHC] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown In-Reply-To: <049.12eb233680e8d62e08f397274c91a741@haskell.org> References: <049.12eb233680e8d62e08f397274c91a741@haskell.org> Message-ID: <064.c6244537c66daf381c4daf3c756763d6@haskell.org> #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: inlining, | Specialise, Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: inlining => inlining, Specialise, Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:16:00 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:16:00 -0000 Subject: [GHC] #15606: Don't float out lets in between lambdsa In-Reply-To: <046.a1d628bd4e8b545a45d332101853164d@haskell.org> References: <046.a1d628bd4e8b545a45d332101853164d@haskell.org> Message-ID: <061.e683fbf2ea560e3e971a6e09219be96c@haskell.org> #15606: Don't float out lets in between lambdsa -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 10:44:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 10:44:12 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.7215ae7ed165056eec4d206b25d5007d@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): @simonpj I will add a note for this one before submitting a MR. @hvr Yes. With the new approach there is no interaction at all as we don't perform any substitution in Core anymore. Whenever the NCG has to embed a big chunk of bytes, it can use the ".incbin" technique. If we add literals that use `ByteArray`, we can easily dump them into a file too, whatever their actual contents is: big `ByteArray`s are already pinned by GHC so we just have to `write` them by using their address and size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 11:19:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 11:19:01 -0000 Subject: [GHC] #15712: GHC panic with -XDerivingVia In-Reply-To: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> References: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> Message-ID: <066.09b9e468fcf92916e8ecaa47ca0e110a@haskell.org> #15712: GHC panic with -XDerivingVia -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: DerivingVia Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): With HEAD, and GHC 8.6, for the code in comment:2 I get {{{ T15712.hs:20:16: error: • Expecting one more argument to ‘GEndo’ Expected kind ‘* -> *’, but ‘GEndo’ has kind ‘(* -> *) -> * -> *’ • In the first argument of ‘Codensity’, namely ‘GEndo’ In the newtype declaration for ‘LogicT’ | 20 | (Codensity GEndo) | ^^^^^ }}} Can others confirm? If so, could someone add a regression test and close? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 12:04:38 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 12:04:38 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.45808943cdec56906330378bbb79ce32@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16190 | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have made a patch to add an helper to TH to create "bytes" primitives: https://gitlab.haskell.org/hsyl20/ghc/tree/hsyl20-T14741 Using it we can patch `file-embed` like this: {{{ 19c19 < module Data.FileEmbed --- > module FileEmbed 49,53c49 < #if MIN_VERSION_template_haskell(2,5,0) < , Lit (StringL, StringPrimL, IntegerL) < #else < , Lit (StringL, IntegerL) < #endif --- > , Lit (..) 60a57 > import Language.Haskell.TH 65a63 > import qualified Data.ByteString.Internal as B 154c152,156 < #if MIN_VERSION_template_haskell(2, 8, 0) --- > #if MIN_VERSION_template_haskell(2, 15, 0) > `AppE` LitE (bytesPrimL ( > let B.PS ptr off sz = bs > in mkBytes ptr (fromIntegral off) (fromIntegral sz)))) > #elif MIN_VERSION_template_haskell(2, 8, 0) }}} Using previous patches for #16198 and #16190, we get the following results when we embed a file of the given size: * V1: HEAD + patch for #16198 * V2: V1 + patch for #16190 (default threshold set to 500K) * V3: V2 + this patch || Size || 8.6.3 || V1 || V2 || V3 || Gain (V3 over v2) || || 128 || 2.650 || 2.331 || 2.346 || 2.291 || +2% || || 3K || 2.651 || 2.289 || 2.290 || 2.310 || -1% || || 30K || 2.590 || 2.353 || 2.307 || 2.299 || +0% || || 100K || 2.717 || 2.379 || 2.389 || 2.298 || +4% || || 500K || 3.621 || 2.814 || 2.331 || 2.315 || +1% || || 1M || 4.694 || 3.526 || 2.654 || 2.320 || +12% || || 2M || 6.784 || 4.668 || 2.650 || 2.350 || +11% || || 3M || 8.851 || 5.616 || 3.073 || 2.400 || +22% || || 30M || 63.181 || 34.318 || 8.517 || 3.390 || +60% || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 12:17:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 12:17:25 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.c400ca64a783837da29c1fb54ef3b37f@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Comment (by mikael.urankar): I managed to build ghc-8.6.3 on FreeBSD powerpc64: https://reviews.freebsd.org/D18886 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:03:34 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:03:34 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor In-Reply-To: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> References: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> Message-ID: <066.fe5dcdff711ab910ded7d5e415ba1534@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: DeriveFunctor | deriving RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That's fine, `newtype` works and it's a contrived example. I agree the gain isn't worth it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:04:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:04:15 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.3805895a1661b8ec0a17693cf3cddcf1@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions, Simplifier Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: seq, deepseq, evaluate, exceptions => seq, deepseq, evaluate, exceptions, Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:07:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:07:12 -0000 Subject: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.c9d06dd92443d102e68e26505eb48aff@haskell.org> #9279: Local wrapper function remains in final program; result = extra closure allocation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift, | Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: LateLamLift => LateLamLift, Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:08:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:08:49 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.beb7472a4c2038f539f3b23932245d69@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15813 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #15813 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:09:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:09:39 -0000 Subject: [GHC] #15813: -Wredundant-constraints emits warning even if constraint is narrowing type (was: -Wredundant-constrains emits warning even if constraint is narrowing type) In-Reply-To: <050.e962430edfc77ee7de83579b620f9675@haskell.org> References: <050.e962430edfc77ee7de83579b620f9675@haskell.org> Message-ID: <065.cd20ba9e2622780b9924e84370aed033@haskell.org> #15813: -Wredundant-constraints emits warning even if constraint is narrowing type -------------------------------------+------------------------------------- Reporter: jvanbruegge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #16154 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #16154 Comment: I have not dug into this, but I bet it's the same as #16154, which has a good explanation of the cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:10:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:10:04 -0000 Subject: [GHC] #15813: -Wredundant-constraints emits warning even if constraint is narrowing type In-Reply-To: <050.e962430edfc77ee7de83579b620f9675@haskell.org> References: <050.e962430edfc77ee7de83579b620f9675@haskell.org> Message-ID: <065.e5b2cd2e70c81a08889a016448967bbb@haskell.org> #15813: -Wredundant-constraints emits warning even if constraint is narrowing type -------------------------------------+------------------------------------- Reporter: jvanbruegge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #16154 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:11:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:11:30 -0000 Subject: [GHC] #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory In-Reply-To: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> References: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> Message-ID: <062.a1887804353dd0cd6628288d7c6a5703@haskell.org> #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:12:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:12:06 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.0927a44fe6783c6b680bfb5815e005b6@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:15:16 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:15:16 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor In-Reply-To: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> References: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> Message-ID: <066.36d36f9d573128a426a89643ce80bd39@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | Keywords: DeriveFunctor | deriving RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:38:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:38:25 -0000 Subject: [GHC] #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor In-Reply-To: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> References: <051.f433fec9cb0b9f98a12481ec1c097785@haskell.org> Message-ID: <066.5b1a09c4f3d6d9c05a461be3fbe18074@haskell.org> #16194: deriving, wrong code: newtype T cat a = MkT ((forall xx. cat xx xx) -> a) deriving stock Functor -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | Keywords: DeriveFunctor | deriving RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thought: The second representation (`g & \g' -> f (g' x)`) can maybe be captured as a newtype with an instance (like `DList` changes the representation of change the representation of `[a]` to `Endo [a]`). GHC would generate the newtype form, the instance takes care of the operation and coerce back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 14:38:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 14:38:41 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.c39cd9625f7910cd951c0deae8cb2ba6@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Unless we misunderstand something, the OOM killer should not act upon VIRT at all, and only kick in if resident memory usage is exhausted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 15:58:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 15:58:17 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.9eba974be1587818df595ff276bf2e04@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Consider the following code: > > {{{#!hs > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ImpredicativeTypes #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeInType #-} > module Bug where > > import Data.Kind > > type KindOf1 (a :: k) = k > type family KindOf2 (a :: k) :: Type where > KindOf2 (a :: k) = k > > data A (a :: Type) :: a -> Type > type family Apply1 (f :: KindOf1 A) (a :: Type) (x :: a) :: Type where > Apply1 f a x = f a x > }}} > > `Apply1` kind-checks, which is just peachy. Note that `Apply1` uses > `KindOf1`, which is a type synonym. Suppose I wanted to swap out > `KindOf1` for `KindOf2`, which is (seemingly) an equivalent type family. > I can define this: > > {{{#!hs > type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) > (a :: Type) > (x :: a) > :: Type where > Apply2 f a x = f a x > }}} > > However, GHC rejects this! > > {{{ > $ /opt/ghc/8.6.2/bin/ghc Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > > Bug.hs:25:10: error: > • Expecting two more arguments to ‘f’ > Expected kind ‘KindOf2 A’, but ‘f’ has kind ‘* -> a -> *’ > • In the first argument of ‘Apply2’, namely ‘f’ > In the type family declaration for ‘Apply2’ > | > 25 | Apply2 f a x = f a x > | ^ > }}} > > I find this quite surprising, since I would have expected `KindOf1` and > `KindOf2` to be functionally equivalent. Even providing explicit > `forall`s does not make it kind-check: > > {{{#!hs > type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) > (a :: Type) > (x :: a) > :: Type where > forall (f :: KindOf2 A) (a :: Type) (x :: a). > Apply2 f a x = f a x > }}} > > Although the error message does change a bit: > > {{{ > $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > > Bug.hs:26:20: error: > • Expected kind ‘* -> a -> *’, but ‘f’ has kind ‘KindOf2 A’ > • In the type ‘f a x’ > In the type family declaration for ‘Apply2’ > | > 26 | Apply2 f a x = f a x > | ^^^^^ > }}} New description: Consider the following code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type KindOf1 (a :: k) = k type family KindOf2 (a :: k) :: Type where KindOf2 (a :: k) = k data A (a :: Type) :: a -> Type type family Apply1 (f :: KindOf1 A) (a :: Type) (x :: a) :: Type where Apply1 f a x = f a x }}} `Apply1` kind-checks, which is just peachy. Note that `Apply1` uses `KindOf1`, which is a type synonym. Suppose I wanted to swap out `KindOf1` for `KindOf2`, which is (seemingly) an equivalent type family. I can define this: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where Apply2 f a x = f a x }}} However, GHC rejects this! {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:25:10: error: • Expecting two more arguments to ‘f’ Expected kind ‘KindOf2 A’, but ‘f’ has kind ‘* -> a -> *’ • In the first argument of ‘Apply2’, namely ‘f’ In the type family declaration for ‘Apply2’ | 25 | Apply2 f a x = f a x | ^ }}} I find this quite surprising, since I would have expected `KindOf1` and `KindOf2` to be functionally equivalent. Even providing explicit `forall`s does not make it kind-check: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where forall (f :: KindOf2 A) (a :: Type) (x :: a). Apply2 f a x = f a x }}} Although the error message does change a bit: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:26:20: error: • Expected kind ‘* -> a -> *’, but ‘f’ has kind ‘KindOf2 A’ • In the type ‘f a x’ In the type family declaration for ‘Apply2’ | 26 | Apply2 f a x = f a x | ^^^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:01:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:01:36 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.4f3124ff1b6e96794aa83c4ab08dd1c1@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm really not sure what to do about this. If OpenShift is really killing processes based on their virtual memory reservation size then this really seems like a bug in OpenShift. Can you describe how in particular the process is being killed? Is it really the kernel OOM killer? Is it a cgroup memory limit? I have found possibly relevant [[https://developers.redhat.com/blog/2017/03/14/java-inside- docker/|article]] about Docker and the JVM which suggests it may be the latter. The JVM apparently has the (experimental) ability to query the memory limits of its containing cgroup. We could do the same if this is really the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:05:40 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:05:40 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.0dbf195e1cacd8d14516201b4581dee4@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): While implementing visible dependent quantification (VDQ), I decided to revisit commment:2. Here are some of my findings: * I think (4) and (5) are ultimately non-issues, at least for the time being. This is because you won't be able to define `f` (or `g` or `h`) in the first place: {{{ Bug.hs:17:6: error: • Illegal visible, dependent quantification in the type of a term: forall a -> a -> * (GHC does not yet support this) • In the expansion of type synonym ‘KindOf1’ In the type signature: f :: KindOf1 A | 17 | f :: KindOf1 A | ^^^^^^^^^ }}} Since terms aren't meant to have types with VDQ in them, I don't think it's worth fretting over (4) and (5). Of course, if VDQ //does// ever become permitted in terms, perhaps this will pop back up. * (1) appears to be unrelated to VDQ and is actually a quirk of `ImpredicativeTypes`. Here is an example to illustrate what I mean: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family F (f :: forall a. a -> Type) where F f = f Int }}} This doesn't typecheck: {{{ Bug.hs:9:5: error: • Expected kind ‘forall a. a -> *’, but ‘f’ has kind ‘* -> k0’ • In the first argument of ‘F’, namely ‘f’ In the type family declaration for ‘F’ | 9 | F f = f Int | ^ }}} However, if you enable `ImpredicativeTypes`, then it //does// typecheck! It's unclear to me why exactly that is, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:13:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:13:13 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.c9fff72e3e4b7d6f7465a50f0210892c@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you don't have impredicative-types, then surely the example in the second bullet of comment:5 should be rejected! But still, the error message looks deeply strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:16:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:16:28 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.9f4d5823d7adc785ae3a2091923211ca@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, I am in agreement with you that the program in the second bullet point of comment:5 should be rejected if `ImpredicativeTypes` is not enabled. I am simply wondering if it being accepted //with// `ImpredicativeTypes` enabled should count as a bug in its own right. (It's such a squirrelly extension that I can never tell whether it's working as intended or not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:36:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:36:11 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.5b75b42afdcbeff7cb557c354160eb82@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Right, I think that would be the best solution for now. We can always revisit this later, when/if we think about a non-hacky solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:54:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:54:15 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables Message-ID: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE PartialTypeSignatures #-} f :: _ -> _ f x = x }}} With GHC 8.6 we got {{{ T16152.hs:10:6: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘w’ Where: ‘w’ is a rigid type variable bound by the inferred type of f :: w -> w at T16152.hs:11:1-7 • In the type signature: f :: _ -> _ | 10 | f :: _ -> _ | ^ T16152.hs:10:11: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘w’ Where: ‘w’ is a rigid type variable bound by the inferred type of f :: w -> w at T16152.hs:11:1-7 • In the type signature: f :: _ -> _ | 10 | f :: _ -> _ | ^ }}} But with HEAD we get {{{ T16152.hs:10:6: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘_’ Where: ‘_’ is a rigid type variable bound by the inferred type of f :: _ -> _ at T16152.hs:11:1-7 • In the type ‘_ -> _’ In the type signature: f :: _ -> _ | 10 | f :: _ -> _ | ^ T16152.hs:10:11: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘_’ Where: ‘_’ is a rigid type variable bound by the inferred type of f :: _ -> _ at T16152.hs:11:1-7 • In the type ‘_ -> _’ In the type signature: f :: _ -> _ | 10 | f :: _ -> _ | ^ }}} Saying "Found type wildcard ‘_’ standing for ‘_’" is unhelpful. The "w" form is much better. The change is caused by {{{ commit 17bd163566153babbf51adaff8397f948ae363ca Author: mynguyen Date: Tue Dec 18 11:52:26 2018 -0500 Visible kind application }}} which has this patch {{{ -newWildTyVar _name +newWildTyVar = do { kind <- newMetaKindVar ; uniq <- newUnique ; details <- newMetaDetails TauTv - ; let name = mkSysTvName uniq (fsLit "w") + ; let name = mkSysTvName uniq (fsLit "_") tyvar = (mkTcTyVar name kind details) ; traceTc "newWildTyVar" (ppr tyvar) ; return tyvar } }}} What was the reason for this change? Can we change "_" back to "w" please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:54:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:54:25 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.4e57182bdc5297e524e0dc563d9632cb@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 16:56:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 16:56:24 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.9457df3b522628da21e3cb859e883be1@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PartialTypeSignatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 17:10:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 17:10:41 -0000 Subject: [GHC] #16078: Hide -Weverything warnings for GHCi internals In-Reply-To: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> References: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> Message-ID: <062.dce743b6c28427b33f9f98e43e0d0a29@haskell.org> #16078: Hide -Weverything warnings for GHCi internals -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * version: 8.6.2 => 8.7 Old description: > Consider > > Bar.hs > {{{ > module Bar where > }}} > > Main.hs > {{{ > import Bar > > main :: IO () > main = print "" > }}} > > `stack ghci Main.hs --ghc-options -Weverything` produces > > {{{ > ... > GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help > > :1:1: warning: [-Wmissing-local-signatures] > Polymorphic local binding with no type signature: > _compileParsedExpr :: forall a. GHC.Types.IO a -> GHC.Types.IO a > > :1:1: warning: [-Wmissing-import-lists] > The module `Prelude' does not have an explicit import list > Loaded GHCi configuration from C:\Users\ericcro\Desktop\VPC-Key- > Distribution\src\.ghci > > : warning: [-Wmissing-home-modules] > Modules are not listed in command line but needed for compilation: > Bar > [1 of 2] Compiling Bar ( Bar.hs, interpreted ) > ... > }}} > > Those three errors have nothing to do with my code, and seem to be > related to the internals of how GHCi works. It would be nice to hide all > three. New description: Consider Bar.hs {{{ module Bar where }}} Main.hs {{{ import Bar main :: IO () main = print "" }}} `ghci Main.hs -Weverything` produces {{{ ... GHCi, version 8.7.20190113: http://www.haskell.org/ghc/ :? for help :1:1: warning: [-Wmissing-local-signatures] Polymorphic local binding with no type signature: _compileParsedExpr :: forall a. GHC.Types.IO a -> GHC.Types.IO a :1:1: warning: [-Wmissing-import-lists] The module `Prelude' does not have an explicit import list : warning: [-Wmissing-home-modules] Modules are not listed in command line but needed for compilation: Bar [1 of 2] Compiling Bar ( Bar.hs, interpreted ) ... }}} Those three errors have nothing to do with my code, and seem to be related to the internals of how GHCi works. It would be nice to hide all three. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 17:50:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 17:50:39 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.a2dfbab33688099a2611e5b6d26a2861@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => invalid Comment: I've opened a [https://github.com/commercialhaskell/stack/issues/4518 stack bug] since I was unable to reproduce using cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 18:21:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 18:21:54 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.f4dd335065de6b752a5dd46619694d5d@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): (2) might also be its own issue, since you can trigger the "expecting more arguments" error without VDQ: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where type family F type family G (f :: F) where G f = f Int }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:5: error: • Expecting one more argument to ‘f’ Expected kind ‘F’, but ‘f’ has kind ‘* -> k0’ • In the first argument of ‘G’, namely ‘f’ In the type family declaration for ‘G’ | 8 | G f = f Int | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 19:38:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 19:38:11 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.6548d0e57eacb64800893386bee31228@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wonder if (3) has anything to do with #9269? `KindOf2 A` is a bit weird in that it's an application of a type family that returns `forall a -> a -> Type`, which is a polymorphic type. Normally, GHC disallows that—you wouldn't be able to define `type family FAA where FAA = forall a -> a -> Type`, for instance. Yet `KindOf2` offers a way around this restriction, so perhaps (3) is a manifestation of GHC trying to deal with something it doesn't know how to reason about. Then again, `KindOf2 A` seems to work in other places, as comment:1 demonstrates. It's just in type family equations where things go haywire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 19:38:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 19:38:30 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.179f169c9fe89fa2af0431324905808e@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: 15411 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/81 -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => closed * resolution: => fixed * related: => 15411 * blockedby: 15411 => Comment: Replying to [comment:44 mikael.urankar]: > I managed to build ghc-8.6.3 on FreeBSD powerpc64: https://reviews.freebsd.org/D18886 Excellent. I'll switch my PowerMac to FreeBSD when GHC is available for it in ports. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 19:52:19 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 19:52:19 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.79e3dd5ee64c07f68f1984258d29cd14@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D5051 (reverted), Phab:D5165, Phab:D5178, MR:103 => Phab:D5051 (reverted), Phab:D5165, Phab:D5178, MR:103, MR:146 Comment: Last bug is fixed in MR:146. Unfortunately we won't be able to test this on CI as this program takes forever to run in non-threaded configurations. It'd be great to have some tests for the stuff we fixed in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 20:34:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 20:34:37 -0000 Subject: [GHC] #13452: Lock .tix file In-Reply-To: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> References: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> Message-ID: <060.08a8d3cbef649926e6fcda77c44b08ae@haskell.org> #13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ramirez7): A related question: If I have multiple Haskell green threads (in the same process) in my tests, are the updates to the {{{tix}}} files thread-safe? I couldn't find any statement on the matter in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 20:52:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 20:52:11 -0000 Subject: [GHC] #16187: Hadrian: Build fails when using absolute path for build root In-Reply-To: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> References: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> Message-ID: <060.645d7447700426ed092ebb6e4cc1e4fd@haskell.org> #16187: Hadrian: Build fails when using absolute path for build root -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian build Resolution: | root relative absolute path Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sykloid): I'm trying to tackle this issue as a beginner get-started-on-ghc task. This particular problem is caused by incorrect argument construction in `hadrian/src/Settings/Builders/Cabal:cabalBuilderArgs`; but other errors pop up when that's fixed, which I'm working on now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 18 21:13:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Jan 2019 21:13:07 -0000 Subject: [GHC] #16187: Hadrian: Build fails when using absolute path for build root In-Reply-To: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> References: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> Message-ID: <060.8a7e831f990ec630bd8ea65054c71f36@haskell.org> #16187: Hadrian: Build fails when using absolute path for build root -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian build Resolution: | root relative absolute path Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Hi @sykloid! Many thanks for taking this up. If you need any help navigating Hadrian code base, please don't hesitate to get in touch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 01:25:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 01:25:20 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.fc7f12445f6996dd4dc8db2fd5b3d56c@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Yes. Please, please let us not ever bring back ghc-cabal. Can you see the horror in my eyes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 05:40:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 05:40:14 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.4cdcb20b8216096a979f5faa473aab09@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * owner: (none) => harpocrates Comment: Good to hear! I'll hack up a sed solution that'll live in the generated install script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 09:31:08 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 09:31:08 -0000 Subject: [GHC] #15381: Write documentation for iserv-proxy In-Reply-To: <046.67d927d07f2686022ddcec4bb1097911@haskell.org> References: <046.67d927d07f2686022ddcec4bb1097911@haskell.org> Message-ID: <061.15c1f37026d90d5bd5a541d6e7410c39@haskell.org> #15381: Write documentation for iserv-proxy -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Angerman, we really ought to try to finish this up for 8.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 09:48:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 09:48:25 -0000 Subject: [GHC] #13452: Lock .tix file In-Reply-To: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> References: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> Message-ID: <060.c2e7bf29bbd6ff3ebbefe5ebe1439a5b@haskell.org> #13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe multiple Haskell threads should be dealt with properly in the current implementation. If not this would certainly be a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 11:11:06 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 11:11:06 -0000 Subject: [GHC] #14976: WebAssembly support In-Reply-To: <043.2fbab8f0c58823e06aed87c5b9fa392c@haskell.org> References: <043.2fbab8f0c58823e06aed87c5b9fa392c@haskell.org> Message-ID: <058.00fc81164d861a9c523e971332956460@haskell.org> #14976: WebAssembly support -------------------------------------+------------------------------------- Reporter: sven | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: wasm, | webassembly Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): > I would like to suggest adding a wasm backend to GHC. I'd like to point out that this is the primary goal of the webGHC project, i.e. to eventually upstream its wasm backend into GHC proper! Quoting https://webghc.github.io/2019/01/18/state-of-webghc- january-2019.html: ''I want to explain that the prime directive of WebGHC thus far has been to ensure its upstream-ability. The WebGHC project aims to add a WebAssembly target to GHC’s existing cross compilation infrastructure. We’re trying to use as much of GHC’s existing infrastructure as possible so that merging upstream eventually is likely, among several other advantages.'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 11:42:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 11:42:25 -0000 Subject: [GHC] #16182: Retainer Profiling is broken In-Reply-To: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> References: <047.952f9f2566fd007a9fca4932c3943c82@haskell.org> Message-ID: <062.c5662db925891276899291968708579b@haskell.org> #16182: Retainer Profiling is broken -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 Comment: I cannot reproduce this using GHC 8.7.20190114 and [https://github.com/hvr/head.hackage/tree/60d797cd2e94757d65d2ca43121d7540a6128674 head.hackage]'s patches for `primitive` //et al.//: {{{ $ cabal new-exec prop-compiled -- +RTS -hr ... Properties Total Passed 582 582 Failed 49 49 Total 631 631 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 11:47:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 11:47:53 -0000 Subject: [GHC] #15726: Don't include Haskeline (and others) in the global package DB In-Reply-To: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> References: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> Message-ID: <059.3264966c5f0fc75aa57ac1b3ea45211b@haskell.org> #15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 bgamari]: > > Are you sure the original issue why we started properly registering GHCi's dependencies around GHC 7.8 has been dealt with? Otherwise this will just throw us back to square one with the bugs/issues we had pre-7.8. > > Not at all; can you refresh our memories on what those issues were? comment:ticket:8919:17 gives a summary of the issues involved which eventually lead to 4caadb7cbee5c176abb99df25c4cc1657ae57f40; and you can find some potential approaches to addressing the issue mentioned in the surrounding discussion. Note however, that `lib:Cabal` has also slowly been acquiring more dependencies, such as `lib:mtl`, `lib:text` or `lib:parsec` (and I've recently realised that the option of not bundling `lib:Cabal` with GHC is not feasible anymore for reasons related to catch-22s in the bootstrapping process). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 12:44:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 12:44:18 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) Message-ID: <050.809cff7906dca54b71168422e3269d5a@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #16188 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program passes Core Lint on GHC 8.6.3: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind ----- -- singletons machinery ----- data family Sing :: forall k. k -> Type data SomeSing :: Type -> Type where SomeSing :: Sing (a :: k) -> SomeSing k ----- -- (Simplified) GHC.Generics ----- class Generic (a :: Type) where type Rep a :: Type from :: a -> Rep a to :: Rep a -> a class PGeneric (a :: Type) where -- type PFrom ... type PTo (x :: Rep a) :: a class SGeneric k where -- sFrom :: ... sTo :: forall (a :: Rep k). Sing a -> Sing (PTo a :: k) ----- class SingKind k where type Demote k :: Type -- fromSing :: ... toSing :: Demote k -> SomeSing k genericToSing :: forall k. ( SingKind k, SGeneric k, SingKind (Rep k) , Generic (Demote k), Rep (Demote k) ~ Demote (Rep k) ) => Demote k -> SomeSing k genericToSing d = withSomeSing @(Rep k) (from d) $ SomeSing . sTo withSomeSing :: forall k r . SingKind k => Demote k -> (forall (a :: k). Sing a -> r) -> r withSomeSing x f = case toSing x of SomeSing x' -> f x' }}} But not on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: $ @ 'LiftedRep @ (forall (a :: Rep k_a1cV). Sing a -> SomeSing k_a1cV) @ (SomeSing k_a1cV) (withSomeSing @ (Rep k_a1cV) @ (SomeSing k_a1cV) $dSingKind_a1d5 ((from @ (Demote k_a1cV) $dGeneric_a1d7 (d_aX7 `cast` (Sub co_a1dK :: Demote k_a1cV[sk:1] ~R# Demote k_a1cV[sk:1]))) `cast` (Sub (Sym (Sym co_a1dR ; Sym co_a1dM) ; (Sym co_a1dQ ; (Demote (Sym co_a1dO))_N)) :: Rep (Demote k_a1cV[sk:1]) ~R# Demote (Rep k_a1cV[sk:1])))) (\ (@ (a_a1dc :: Rep k_a1cV)) -> let { $dSGeneric_a1dm :: SGeneric k_a1cV [LclId] $dSGeneric_a1dm = $dSGeneric_a1cY } in . @ (Sing (PTo Any)) @ (SomeSing k_a1cV) @ (Sing Any) (SomeSing @ k_a1cV @ (PTo Any)) ((sTo @ k_a1cV $dSGeneric_a1dm @ Any) `cast` (Sym (Sing (Sym co_a1dO) (Sym (GRefl nominal Any co_a1dO)))_R ->_R _R :: (Sing Any -> Sing (PTo Any)) ~R# (Sing Any -> Sing (PTo Any))))) Argument value doesn't match argument type: Fun type: (forall (a :: Rep k_a1cV). Sing a -> SomeSing k_a1cV) -> SomeSing k_a1cV Arg type: forall (a :: Rep k_a1cV). Sing Any -> SomeSing k_a1cV Arg: \ (@ (a_a1dc :: Rep k_a1cV)) -> let { $dSGeneric_a1dm :: SGeneric k_a1cV [LclId] $dSGeneric_a1dm = $dSGeneric_a1cY } in . @ (Sing (PTo Any)) @ (SomeSing k_a1cV) @ (Sing Any) (SomeSing @ k_a1cV @ (PTo Any)) ((sTo @ k_a1cV $dSGeneric_a1dm @ Any) `cast` (Sym (Sing (Sym co_a1dO) (Sym (GRefl nominal Any co_a1dO)))_R ->_R _R :: (Sing Any -> Sing (PTo Any)) ~R# (Sing Any -> Sing (PTo Any)))) *** Offending Program *** genericToSing :: forall k. (SingKind k, SGeneric k, SingKind (Rep k), Generic (Demote k), Rep (Demote k) ~ Demote (Rep k)) => Demote k -> SomeSing k [LclIdX] genericToSing = \ (@ k_a1cV) ($dSingKind_a1cX :: SingKind k_a1cV) ($dSGeneric_a1cY :: SGeneric k_a1cV) ($dSingKind_a1cZ :: SingKind (Rep k_a1cV)) ($dGeneric_a1d0 :: Generic (Demote k_a1cV)) ($d~_a1d1 :: Rep (Demote k_a1cV) ~ Demote (Rep k_a1cV)) -> let { co_a1dQ :: Demote (Rep k_a1cV) ~# Demote (Rep k_a1cV) [LclId[CoVarId]] co_a1dQ = CO: _N } in let { co_a1dO :: Rep k_a1cV ~# Rep k_a1cV [LclId[CoVarId]] co_a1dO = CO: _N } in let { $dSingKind_a1dT :: SingKind (Rep k_a1cV) [LclId] $dSingKind_a1dT = $dSingKind_a1cZ `cast` (Sub (Sym (SingKind (Sym co_a1dO))_N) :: SingKind (Rep k_a1cV[sk:1]) ~R# SingKind (Rep k_a1cV[sk:1])) } in let { $dSingKind_a1d5 :: SingKind (Rep k_a1cV) [LclId] $dSingKind_a1d5 = $dSingKind_a1dT `cast` ((SingKind (Sym co_a1dO))_R :: SingKind (Rep k_a1cV[sk:1]) ~R# SingKind (Rep k_a1cV[sk:1])) } in let { co_a1dM :: Rep (Demote k_a1cV) ~# Rep (Demote k_a1cV) [LclId[CoVarId]] co_a1dM = CO: _N } in let { co_a1dK :: Demote k_a1cV ~# Demote k_a1cV [LclId[CoVarId]] co_a1dK = CO: _N } in let { $dGeneric_a1dU :: Generic (Demote k_a1cV) [LclId] $dGeneric_a1dU = $dGeneric_a1d0 `cast` (Sub (Sym (Generic (Sym co_a1dK))_N) :: Generic (Demote k_a1cV[sk:1]) ~R# Generic (Demote k_a1cV[sk:1])) } in let { $dGeneric_a1d7 :: Generic (Demote k_a1cV) [LclId] $dGeneric_a1d7 = $dGeneric_a1dU } in case eq_sel @ * @ (Rep (Demote k_a1cV)) @ (Demote (Rep k_a1cV)) $d~_a1d1 of co_a1dI { __DEFAULT -> let { co_a1dR :: Rep (Demote k_a1cV) ~# Demote (Rep k_a1cV) [LclId[CoVarId]] co_a1dR = CO: ((Sym co_a1dM ; (Rep (Sym co_a1dK))_N) ; co_a1dI) ; Sym (Sym co_a1dQ ; (Demote (Sym co_a1dO))_N) } in \ (d_aX7 :: Demote k_a1cV) -> $ @ 'LiftedRep @ (forall (a :: Rep k_a1cV). Sing a -> SomeSing k_a1cV) @ (SomeSing k_a1cV) (withSomeSing @ (Rep k_a1cV) @ (SomeSing k_a1cV) $dSingKind_a1d5 ((from @ (Demote k_a1cV) $dGeneric_a1d7 (d_aX7 `cast` (Sub co_a1dK :: Demote k_a1cV[sk:1] ~R# Demote k_a1cV[sk:1]))) `cast` (Sub (Sym (Sym co_a1dR ; Sym co_a1dM) ; (Sym co_a1dQ ; (Demote (Sym co_a1dO))_N)) :: Rep (Demote k_a1cV[sk:1]) ~R# Demote (Rep k_a1cV[sk:1])))) (\ (@ (a_a1dc :: Rep k_a1cV)) -> let { $dSGeneric_a1dm :: SGeneric k_a1cV [LclId] $dSGeneric_a1dm = $dSGeneric_a1cY } in . @ (Sing (PTo Any)) @ (SomeSing k_a1cV) @ (Sing Any) (SomeSing @ k_a1cV @ (PTo Any)) ((sTo @ k_a1cV $dSGeneric_a1dm @ Any) `cast` (Sym (Sing (Sym co_a1dO) (Sym (GRefl nominal Any co_a1dO)))_R ->_R _R :: (Sing Any -> Sing (PTo Any)) ~R# (Sing Any -> Sing (PTo Any))))) } }}} I'm not sure if this is related to #16188 (see https://ghc.haskell.org/trac/ghc/ticket/16188#comment:1), but this Core Lint error is technically different from the one in that ticket, so I decided to open a new issue for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 12:44:42 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 12:44:42 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.f95c65bc399f87a68b6fc3d91b665d86@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16204 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #16204 Comment: #16204 is possibly related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 12:57:37 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 12:57:37 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.a3606d84457db5a7f455362cca218102@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16204 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's unclear to me if this is the same issue or not, but in this slightly modified version of the original program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Kind (Type) import Data.Type.Bool (type (&&)) import Data.Type.Equality ((:~:)(..)) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data family Sing :: forall k. k -> Type data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True (%&&) :: forall (x :: Bool) (y :: Bool). Sing x -> Sing y -> Sing (x && y) SFalse %&& _ = SFalse STrue %&& a = a data RegExp :: Type -> Type where App :: RegExp t -> RegExp t -> RegExp t data instance Sing :: forall t. RegExp t -> Type where SApp :: Sing re1 -> Sing re2 -> Sing (App re1 re2) data ReNotEmptySym0 :: forall t. RegExp t ~> Bool type instance Apply ReNotEmptySym0 r = ReNotEmpty r type family ReNotEmpty (r :: RegExp t) :: Bool where ReNotEmpty (App re1 re2) = ReNotEmpty re1 && ReNotEmpty re2 sReNotEmpty :: forall t (r :: RegExp t). Sing r -> Sing (Apply ReNotEmptySym0 r :: Bool) sReNotEmpty (SApp sre1 sre2) = sReNotEmpty sre1 %&& sReNotEmpty sre2 blah :: forall (t :: Type) (re :: RegExp t). Sing re -> (ReNotEmpty re :~: True) -> () blah (SApp sre1 sre2) Refl = case (sReNotEmpty sre1, sReNotEmpty sre2) of (STrue, STrue) -> () }}} You actually get different pattern-match coverage checker warnings on GHC 8.6 and HEAD! GHC 8.6 compiles with no warnings, whereas on GHC HEAD you get: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:49:5: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (SFalse, _) | 49 | = case (sReNotEmpty sre1, sReNotEmpty sre2) of | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190114 for x86_64-unknown-linux): buildKindCoercion Any ReNotEmpty re2_a1mg Bool t_a1ma Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:2427:9 in ghc:Coercion }}} It could just be that the types have become so screwed up (due to the explanation in comment:2) that the coverage checker becomes confused, but I thought this was worth pointing out nonetheless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 13:01:05 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 13:01:05 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) In-Reply-To: <050.809cff7906dca54b71168422e3269d5a@haskell.org> References: <050.809cff7906dca54b71168422e3269d5a@haskell.org> Message-ID: <065.7ce7fbe7cdba112336d9c188115f842a@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16188 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This isn't even the only issue with this program that's surfaced on GHC HEAD. If you use this slightly modified version of `genericToSing` (the only difference is that the explicit `@(Rep k)` argument has been removed): {{{#!hs genericToSing :: forall k. ( SingKind k, SGeneric k, SingKind (Rep k) , Generic (Demote k), Rep (Demote k) ~ Demote (Rep k) ) => Demote k -> SomeSing k genericToSing d = withSomeSing (from d) $ SomeSing . sTo }}} Then GHC 8.6.3 compiles it successfully, whereas GHC HEAD gives a strange error: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:49:33: error: • Could not deduce: Demote k0 ~ Demote (Rep k) from the context: (SingKind k, SGeneric k, SingKind (Rep k), Generic (Demote k), Rep (Demote k) ~ Demote (Rep k)) bound by the type signature for: genericToSing :: forall k. (SingKind k, SGeneric k, SingKind (Rep k), Generic (Demote k), Rep (Demote k) ~ Demote (Rep k)) => Demote k -> SomeSing k at Bug.hs:(45,1)-(48,39) Expected type: Demote k0 Actual type: Rep (Demote k) NB: ‘Demote’ is a non-injective type family The type variable ‘k0’ is ambiguous • In the first argument of ‘withSomeSing’, namely ‘(from d)’ In the expression: withSomeSing (from d) In the expression: withSomeSing (from d) $ SomeSing . sTo • Relevant bindings include d :: Demote k (bound at Bug.hs:49:15) genericToSing :: Demote k -> SomeSing k (bound at Bug.hs:49:1) | 49 | genericToSing d = withSomeSing (from d) $ SomeSing . sTo | ^^^^^^ }}} It's unclear to me if this issue is the same as the one causing the Core Lint error or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 13:27:05 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 13:27:05 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.d2417a903ca8f5603c67c3cace008b9e@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) * status: closed => new * resolution: invalid => Comment: No need to file a `stack` bug, as your initial hunch was correct: this is a GHC bug. You can reproduce this issue using nothing but GHC and your repro case: {{{#!hs {-# LANGUAGE BangPatterns #-} -- NetworkRequestHeader.hs module NetworkRequestHeader (parseHeaderLines, parseRequestLine) where import Control.Exception import Control.Monad import Data.ByteString.Internal (ByteString(..), memchr) import Data.Word import Foreign.ForeignPtr (withForeignPtr) import Foreign.Ptr (Ptr, plusPtr, minusPtr, nullPtr) import Foreign.Storable (peek) -- | Error types for bad 'Request'. data InvalidRequest = NonHttp instance Show InvalidRequest where show _ = "" instance Exception InvalidRequest parseHeaderLines :: [ByteString] -> IO (ByteString ,ByteString -- Path ,ByteString -- Path, parsed ) parseHeaderLines [] = throwIO $ NonHttp parseHeaderLines (firstLine:_) = do (method, path') <- parseRequestLine firstLine let path = path' return (method, path', path) parseRequestLine :: ByteString -> IO (ByteString ,ByteString) parseRequestLine (PS fptr off len) = withForeignPtr fptr $ \ptr -> do when (len < 14) $ throwIO NonHttp let methodptr = ptr `plusPtr` off limptr = methodptr `plusPtr` len lim0 = fromIntegral len pathptr0 <- memchr methodptr 32 lim0 -- ' ' when (pathptr0 == nullPtr || (limptr `minusPtr` pathptr0) < 11) $ throwIO NonHttp let pathptr = pathptr0 `plusPtr` 1 lim1 = fromIntegral (limptr `minusPtr` pathptr0) httpptr0 <- memchr pathptr 32 lim1 -- ' ' when (httpptr0 == nullPtr || (limptr `minusPtr` httpptr0) < 9) $ throwIO NonHttp let httpptr = httpptr0 `plusPtr` 1 lim2 = fromIntegral (httpptr0 `minusPtr` pathptr) checkHTTP httpptr queryptr <- memchr pathptr 63 lim2 -- '?' let !method = bs ptr methodptr pathptr0 !path | queryptr == nullPtr = bs ptr pathptr httpptr0 | otherwise = bs ptr pathptr queryptr return (method,path) where check :: Ptr Word8 -> Int -> Word8 -> IO () check p n w = do w0 <- peek $ p `plusPtr` n when (w0 /= w) $ throwIO NonHttp checkHTTP httpptr = do check httpptr 0 72 -- 'H' check httpptr 1 84 -- 'T' check httpptr 2 84 -- 'T' check httpptr 3 80 -- 'P' check httpptr 4 47 -- '/' check httpptr 6 46 -- '.' bs ptr p0 p1 = PS fptr o l where o = p0 `minusPtr` ptr l = p1 `minusPtr` p0 }}} {{{#!hs $ more Main.hs {-# LANGUAGE BangPatterns #-} -- Main.hs module Main (main) where import Network.RequestHeader import Control.Monad main :: IO () main = void $ parseHeaderLines [] }}} {{{ $ ghc -O1 -fforce-recomp -prof -fprof-auto Main.hs [1 of 2] Compiling Network.RequestHeader ( Network\RequestHeader.hs, Network\RequestHeader.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... .\Network\RequestHeader.o:fake:(.text+0x920): undefined reference to `__chkstk_ms' .\Network\RequestHeader.o:fake:(.text+0xc10): undefined reference to `__chkstk_ms' .\Network\RequestHeader.o:fake:(.text+0xc70): undefined reference to `__chkstk_ms' .\Network\RequestHeader.o:fake:(.text+0xdd8): undefined reference to `__chkstk_ms' .\Network\RequestHeader.o:fake:(.text+0xe90): undefined reference to `__chkstk_ms' .\Network\RequestHeader.o:fake:(.text+0xee0): more undefined references to `__chkstk_ms' follow collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} Note that both the `-O1` and `-fprof-auto` flags are required to trigger the linker errors. (This explains why you seemingly couldn't trigger the error with `cabal-install`, as `cabal-install`'s `--enable-profiling` option doesn't imply the `-fprof-auto` flag, whereas `stack`'s `--profile` option does.) Phyx-, any ideas as to what might be causing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 13:49:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 13:49:34 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.5f55f8efe94ed96c324cdfe7bf87bb9d@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's entirely possible that (2) is actually a duplicate of #14319, especially in light of comment:8. (Then again, it's not clear why `KindOf2 A` isn't reducing in that type family equation in the first place—see comment:9.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 14:16:40 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 14:16:40 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.75a054f60f86b914b13dd1254a03b081@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): For whatever reason `libgcc` is not passed to the linker by gcc. Would need to look at what the profiling options pass to the linker. In any case you can work around it by passing `-lgcc` to ghc or add `extra-libraries: gcc` to your cabal file. We should probably add `gcc` explicitly to the libraries list of the rts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 15:08:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 15:08:18 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.6cfb9a50636e392b6daa81b9b6730701@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): @gidyn Indeed we will need detail information on how exactly OpenShift does its killing and what metrics it uses (ideally even a link to the code that sets it up) in order to figure out whether it's even related to the 1 TB VIRT allocation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 16:51:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 16:51:50 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.e1292ca6f979d5828b5146529399a073@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 16:52:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 16:52:14 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.cb668ce6bf328f0874c76d351e4af941@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 17:04:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 17:04:51 -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.0217b1d9fe079c34f23bb68b391f8249@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 17:05:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 17:05:17 -0000 Subject: [GHC] #3701: allow existential wrapper newtypes In-Reply-To: <045.840f456f2d890bcf682319446631153e@haskell.org> References: <045.840f456f2d890bcf682319446631153e@haskell.org> Message-ID: <060.10de43f26ad5ec4df63d03c4e5d32d46@haskell.org> #3701: allow existential wrapper newtypes -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.10.4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 18:49:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 18:49:46 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.c8969e3cc2c9f7e3be8d034cb8251bee@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -------------------------------------+------------------------------------- Comment (by jrp): I don't know whether this is just regular `cabal` hell or an instance of this problem, but running: {{{ cabal new-install parsec Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: ghc-8.6.3/installed-8.6... (user goal) [__1] next goal: process (user goal) [__1] rejecting: process-1.6.5.0 (conflict: ghc => process==1.6.3.0/installed-1.6...) [__1] rejecting: process-1.6.4.0, process-1.6.3.0/installed-1.6..., process-1.6.3.0, process-1.6.2.0, process-1.6.1.0, process-1.6.0.0, process-1.5.0.0, process-1.4.3.0, process-1.4.2.0, process-1.4.1.0, process-1.4.0.0, process-1.3.0.0, process-1.2.3.0, process-1.2.2.0, process-1.2.1.0, process-1.2.0.0, process-1.1.0.2, process-1.1.0.1, process-1.1.0.0, process-1.0.1.5, process-1.0.1.4, process-1.0.1.3, process-1.0.1.2, process-1.0.1.1, process-1.0.0.0 (constraint from user target requires ==1.6.5.0) [__1] fail (backjumping, conflict set: ghc, process) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: process, ghc }}} If an instance of this problem, then I'd recommend an 8.6.4... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 19:05:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 19:05:50 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.8b096528b4b14877d71c90ca07c752cd@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * milestone: => 8.8.1 Comment: Fixed in https://gitlab.haskell.org/ghc/ghc/merge_requests/148. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 19:06:10 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 19:06:10 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.e58eefe9440a59398627d6fbc63aca70@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.4 Comment: Actually, we can even get this in to 8.6.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 19:58:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 19:58:16 -0000 Subject: [GHC] #16103: docs-haddock Hadrian target doesn't work reliably In-Reply-To: <050.924a903dce685538d1f289c25038f6ec@haskell.org> References: <050.924a903dce685538d1f289c25038f6ec@haskell.org> Message-ID: <065.c33978d1395290c3367345efd2332f96@haskell.org> #16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): This is no longer broken. I think the patch to move building Haddock to stage 1 is what fixed it, but I'm not certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 19:59:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 19:59:46 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.32f9fb083d63f4f8ed86dcce059af581@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/147 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/147 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 19 23:30:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Jan 2019 23:30:34 -0000 Subject: [GHC] #16156: Broken tests on Windows In-Reply-To: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> References: <046.5fc15f33d6033ccf8d330115d027a579@haskell.org> Message-ID: <061.c36cc6369d8da44ca40cc155e9ea7d4c@haskell.org> #16156: Broken tests on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Phyx, you mean running the testsuite driver with multiple threads has caused threads to fail? I'll admit I haven't tried running it without threading but I'm not sure we can really afford to do so; the testsuite runs already take altogether far too long on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 08:13:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 08:13:01 -0000 Subject: [GHC] #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault Message-ID: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Keywords: llvm integer- | Operating System: Unknown/Multiple gmp | Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Although I haven't reproduced this locally yet, the `validate-x86_64 -linux-deb9-llvm` CI pipeline (which is allowed to fail) has continuously been failing for `print037(ghci-ext)`. Here's the relevant output: {{{ --- ghci.debugger/scripts/print037.run/print037.stdout.normalised 2019-01-19 11:37:48.698917882 +0000 +++ ghci.debugger/scripts/print037.run/print037.run.stdout.normalised 2019-01-19 11:37:48.698917882 +0000 @@ -1,5 +1,4 @@ smallNeg = -53 smallPos = 89 zero = 0 -largeNeg = -4123841823694876543987265438957349857349 -largePos = 5402398759384752938475029384750298347554 +ghc-stage2: ghc-iserv terminated (-11) *** unexpected failure for print037(ghci-ext) }}} Given that the crash happens only on large integers (i.e. not `S#`), something in the C FFI with the GMP code is probably to blame. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 09:03:04 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 09:03:04 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.fd6026e47d898e7b3848f7d47b1ba2a4@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): [ Help to pin down the cause by 宮里 洸司 (Koji Miyazato) much appreciated ] Probably the same underlying cause, where a let-bound universally quantified function that transforms IO actions to run under a lock, leads to type errors when ApplicativeDo is in use (sometimes for unrelated code in the same module). Removing ApplicativeDo allows the code to compile, as does inlining the let-bound polymorphic value into the call site. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ApplicativeDo #-} module Main where import Control.Concurrent.MVar type Locker = forall a. IO a -> IO a main :: IO () main = do line <- getLine lock <- newMVar () let locker :: Locker locker = withMVar lock . const f line locker f :: String -> Locker -> IO () f line locker = locker $ putStrLn line }}} This fails with: {{{ appdobug.hs:14:13: error: • Couldn't match type ‘a’ with ‘a0’ ‘a’ is a rigid type variable bound by a type expected by the context: Locker at appdobug.hs:14:6-18 Expected type: IO a -> IO a Actual type: IO a0 -> IO a0 • In the second argument of ‘f’, namely ‘locker’ In a stmt of a 'do' block: f line locker In the expression: do line <- getLine lock <- newMVar () let locker :: Locker locker = withMVar lock . const f line locker • Relevant bindings include locker :: IO a0 -> IO a0 (bound at appdobug.hs:13:10) }}} With the value of 'locker' inlined as below, what one would expect to be the "same" code now compiles. The behaviour is sufficiently surprising to perhaps merit another look at this issue. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ApplicativeDo #-} module Main where import Control.Concurrent.MVar type Locker = forall a. IO a -> IO a main :: IO () main = do line <- getLine lock <- newMVar () f line $ withMVar lock . const f :: String -> Locker -> IO () f line locker = locker $ putStrLn line }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 10:15:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 10:15:00 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) In-Reply-To: <050.809cff7906dca54b71168422e3269d5a@haskell.org> References: <050.809cff7906dca54b71168422e3269d5a@haskell.org> Message-ID: <065.8f9fd2b98fdcf5d97ba217e655905d76@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16188 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I simplified to: {{{ #!haskell {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module T16204 where import Data.Kind data family Sing :: forall k. k -> Type type family Rep (a :: Type) :: Type type family PTo (x :: Rep a) :: a sTo :: forall (k :: Type) (a :: Rep k). (Sing a, Sing (PTo a :: k)) sTo = sTo x :: forall (a :: Type). Sing a x = fst sTo }}} This program is rejected (IMO correctly) by 8.6, but gives Core Lint error in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 12:23:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 12:23:50 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.6aa0ca958647b5b27c436ce695754cdf@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: new => closed * resolution: => wontfix Comment: Tried with plain docker, and it worked. Tried with plain Kubernetes, and it worked. Further attempts with OpenShift failed, then one worked, then got `01-index.tar: hPutBuf: resource exhausted (Cannot allocate memory)`. So it does indeed appear that the memory issues were coming from `cabal update`, and not the 1Tb allocation. Apologies for the distraction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 15:33:43 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 15:33:43 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled In-Reply-To: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> References: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> Message-ID: <063.77288e19efd1191cbfc2c28b02d489b6@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T16179.hs Blocked By: | Blocking: Related Tickets: #15839 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/120 -------------------------------------+------------------------------------- Changes (by ckoparkar): * cc: bgamari (added) * status: patch => closed * resolution: => fixed * testcase: => deriving/should_compile/T16179.hs Comment: Fixed by [https://gitlab.haskell.org/ghc/ghc/commit/800d77e882f24066a7f6d818b2606ad8a0e79e02 800d77e8]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 21:31:33 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 21:31:33 -0000 Subject: [GHC] #16206: Run Haddock's test suite in CI Message-ID: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> #16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many changes in GHC affect Haddock's output, breaking its test suite. Recent examples are [https://gitlab.haskell.org/ghc/ghc/commit/53874834b779ad0dfbcde6650069c37926da1b79 5387483] and [https://gitlab.haskell.org/ghc/ghc/commit/7cba71fc25af8287db61f6f6aa80d45ce96404a7 7cba71f]. If cases like these were caught during CI, they could be fixed immediately, avoiding follow-up cleanup work by the Haddock maintainer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 21:35:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 21:35:17 -0000 Subject: [GHC] #16206: Run Haddock's test suite in CI In-Reply-To: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> References: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> Message-ID: <061.4e4dd13b3dec5e3748f9d051e2c60142@haskell.org> #16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 20 22:33:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Jan 2019 22:33:29 -0000 Subject: [GHC] #15613: GHCi command, tracing steps of instance resolution for Constraint or expression In-Reply-To: <051.315b513efc5cd955ece666611620c1e9@haskell.org> References: <051.315b513efc5cd955ece666611620c1e9@haskell.org> Message-ID: <066.298e6655b94cf310c127975652e81b3a@haskell.org> #15613: GHCi command, tracing steps of instance resolution for Constraint or expression -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15610 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Another GHCi command (#15610), `:elab ` traces instance > resolution for ``. This is already something people do by > hand (ticket:10318#comment:6) and would be a great tool for explorers of > Haskell > > {{{ > >> :elab Monoid (a -> b -> ([c], Sum Int)) > Monoid (a -> b -> ([c], Sum Int)) > ==> Monoid (b -> ([c], Sum Int)) > ==> Monoid ([c], Sum Int) > ==> Monoid [c] > ==> Monoid (Sum Int) > ==> Num Int > }}} > > If resolving the type class fails, it can pinpoint what caused it to fail > > {{{ > >> data A > >> :elab Show (A, Int -> Int) > Show (A, Int -> Int) > <~bRZsz NO instance~> > > ==> Show A > > ==> Show (Int -> Int) > > }}} > > A verbose version can explain each step > > {{{ > >> :elab +v Monoid (a -> b -> ([c], Sum Int) > Monoid (a -> b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid (b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid ([c], Sum Int) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid [c] -- Monoid [a] > (‘GHC.Base’) > ==> Monoid (Sum Int) -- Num a => Monoid (Sum a) > (‘Data.Monoid’) > ==> Num Int -- Num Int > (‘GHC.Num’) > }}} > > {{{ > >> :elab +v Num (Int, Float, Rational) > Num (Int, Float, Rational) -- (Num a, Num b, Num c) => Num (a, b, c) > (‘Data.NumInstances.Tuple’) > ==> Num Int -- Num Int > (‘GHC.Num’) > ==> Num Float -- Num Float > (‘GHC.Float’) > ==> Num Rational -- type Rational = Ratio Integer > (‘GHC.Real’) > = Num (Ration Integer) -- Integral a => Num (Ratio a) > (‘GHC.Real’) > ==> Integral Integer -- Integral Integer > (‘GHC.Real’) > }}} > > ---- > > Not the same idea but similar. Listing instance resolution that takes > place in an expression > > {{{ > >> :elab (+) @Int > from: (+) @Int > Num Int > }}} > {{{ > >> :elab2 comparing (length @[]) <> compare > from: length @[] > Foldable [] > > from: comparing (length @[]) > Ord Int > > from: comparing (length @[]) <> compare > Monoid ([a] -> [a] -> Ordering) > ==> Monoid ([a] -> Ordering) > ==> Monoid Ordering > }}} > {{{ > >> :elab2 ask 'a' > from: ask 'a' > MonadReader Char ((->) m) > ==> MonadReader Char ((->) Char) > }}} > > not sure about that last one, or how to visualize them but I think it > gives the right idea. > > Make sure to test it on > https://jpaykin.github.io/papers/paykin_dissertation_2018.pdf > > {{{#!hs > lam > :: (HasLolli exp, KnownNat n, > Div_ (Remove n ctx') (Remove n ctx') ~ '[], > Fresh (Remove n ctx') ~ n, > MergeF (Remove n ctx') '[] ~ Remove n ctx', MergeF ctx' '[] ~ ctx', > Lookup ctx' n ~ 'Just a, AddF n a (Remove n ctx') ~ ctx', > Div_ ctx' ctx' ~ '[]) => > (Var exp n a -> exp ctx' b) -> exp (Remove n ctx') (a -· b) > }}} New description: Another GHCi command (#15610), `:elab ` traces instance resolution for ``. This is already something people do by hand (ticket:10318#comment:6) and would be a great tool for explorers of Haskell {{{ >> :elab Monoid (a -> b -> ([c], Sum Int)) Monoid (a -> b -> ([c], Sum Int)) ==> Monoid (b -> ([c], Sum Int)) ==> Monoid ([c], Sum Int) ==> Monoid [c] ==> Monoid (Sum Int) ==> Num Int }}} If resolving the type class fails, it can pinpoint what caused it to fail {{{ >> data A >> :elab Show (A, Int -> Int) Show (A, Int -> Int) <~bRZsz NO instance~> ==> Show A ==> Show (Int -> Int) }}} A verbose version can explain each step {{{ >> :elab +v Monoid (a -> b -> ([c], Sum Int) Monoid (a -> b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid (b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid ([c], Sum Int) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid [c] -- Monoid [a] (‘GHC.Base’) ==> Monoid (Sum Int) -- Num a => Monoid (Sum a) (‘Data.Monoid’) ==> Num Int -- Num Int (‘GHC.Num’) }}} {{{ >> :elab +v Num (Int, Float, Rational) Num (Int, Float, Rational) -- (Num a, Num b, Num c) => Num (a, b, c) (‘Data.NumInstances.Tuple’) ==> Num Int -- Num Int (‘GHC.Num’) ==> Num Float -- Num Float (‘GHC.Float’) ==> Num Rational -- type Rational = Ratio Integer (‘GHC.Real’) = Num (Ration Integer) -- Integral a => Num (Ratio a) (‘GHC.Real’) ==> Integral Integer -- Integral Integer (‘GHC.Real’) }}} ---- Not the same idea but similar. Listing instance resolution that takes place in an expression {{{ >> :elab (+) @Int from: (+) @Int Num Int }}} {{{ >> :elab2 comparing (length @[]) <> compare from: length @[] Foldable [] from: comparing (length @[]) Ord Int from: comparing (length @[]) <> compare Monoid ([a] -> [a] -> Ordering) ==> Monoid ([a] -> Ordering) ==> Monoid Ordering }}} {{{ >> :elab2 ask 'a' from: ask 'a' MonadReader Char ((->) m) ==> MonadReader Char ((->) Char) }}} not sure about that last one, or how to visualize them but I think it gives the right idea. Make sure to test it on https://jpaykin.github.io/papers/paykin_dissertation_2018.pdf {{{#!hs lam :: (HasLolli exp, KnownNat n, Div_ (Remove n ctx') (Remove n ctx') ~ '[], Fresh (Remove n ctx') ~ n, MergeF (Remove n ctx') '[] ~ Remove n ctx', MergeF ctx' '[] ~ ctx', Lookup ctx' n ~ 'Just a, AddF n a (Remove n ctx') ~ ctx', Div_ ctx' ctx' ~ '[]) => (Var exp n a -> exp ctx' b) -> exp (Remove n ctx') (a -· b) }}} and [https://www.reddit.com/r/haskell/comments/ahu6jp/fun_fact_the_continuation_monad_cont_r_a_has_an/eejuhlq/ this] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 02:24:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 02:24:09 -0000 Subject: [GHC] #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled In-Reply-To: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> References: <048.bb42c8e102ba399adda177e87a397fa5@haskell.org> Message-ID: <063.f495cb93be240b1fe5b7b8ae5d12f7a4@haskell.org> #16179: Mention DerivingStrategies in the warning when DeriveAnyClass and GeneralizedNewtypeDeriving are both enabled -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T16179.hs Blocked By: | Blocking: Related Tickets: #15839 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/120 -------------------------------------+------------------------------------- Comment (by bgamari): Thanks ckoparkar! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 06:19:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 06:19:51 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) (was: Typechecking fails for parallel monad comprehensions with polymorphic let) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.3396e896c8e7ecb817ace1cfd7f5a759@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 10:09:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 10:09:29 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.3f38fe3b6920ff6a4b03b72bdd4b7ee8@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michaelpj): Getting this into 8.6.4 would be fantastic! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 10:55:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 10:55:52 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.7aea6387e5ad56b9480e7d4d86f8e169@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fxcoudert): Without parallel build, the testsuite still fails: {{{ SUMMARY for test run started at Thu Jan 17 10:51:28 2019 GMT 2:38:00 spent to go through 6521 total tests, which gave rise to 25300 test cases, of which 18851 were skipped 28 had missing libraries 6321 expected passes 90 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 1 unexpected failures 8 unexpected stat failures Unexpected passes: driver/should_fail/T12752.run T12752 [unexpected] (normal) Unexpected failures: ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) Unexpected stat failures: perf/compiler/T5631.run T5631 [stat too good] (normal) perf/compiler/parsing001.run parsing001 [stat too good] (normal) perf/compiler/T10370.run T10370 [stat not good enough] (optasm) perf/compiler/T9630.run T9630 [stat not good enough] (normal) perf/haddock/haddock.base.run haddock.base [stat too good] (normal) perf/haddock/haddock.Cabal.run haddock.Cabal [stat too good] (normal) perf/should_run/T9203.run T9203 [stat too good] (normal) perf/space_leaks/T4029.run T4029 [stat not good enough] (ghci) }}} Full output here: https://gist.github.com/fxcoudert/7fe4950fec822a65be59563100655658 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 12:06:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 12:06:28 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm In-Reply-To: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> References: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> Message-ID: <060.6dae5214b3d0f881ff77c6beeab41e14@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"f035504b573b9684d53a6d035f8726672c1b0190/ghc" f035504/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f035504b573b9684d53a6d035f8726672c1b0190" Add support for ASM foreign files (.s) in TH (#16180) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 12:06:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 12:06:46 -0000 Subject: [GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base` In-Reply-To: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> References: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> Message-ID: <062.0fed30684fb9d451457a46c024532562@haskell.org> #16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: base, | profunctor, QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 13:06:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 13:06:34 -0000 Subject: [GHC] #16180: Make addForeignFilePath support asm In-Reply-To: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> References: <045.10fd33328046a3967cf012fc6e35b209@haskell.org> Message-ID: <060.d3424c53799420315630c016646714f3@haskell.org> #16180: Make addForeignFilePath support asm -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:03:48 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:03:48 -0000 Subject: [GHC] #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows Message-ID: <049.5f62cbbe05a855c9491b690e69a87da5@haskell.org> #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows -------------------------------------+------------------------------------- Reporter: cromachina | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `cabal new-install wreq-0.5.3.1 -j1` Observe ghc.exe seemingly stuck in an infinite loop after the following line with no allocating or IO occurring: `[ 5 of 15] Compiling Network.Wreq.Internal.Lens ( Network\Wreq\Internal\Lens.hs, dist\build\Network\Wreq\Internal\Lens.o )` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:15:13 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:15:13 -0000 Subject: [GHC] #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows In-Reply-To: <049.5f62cbbe05a855c9491b690e69a87da5@haskell.org> References: <049.5f62cbbe05a855c9491b690e69a87da5@haskell.org> Message-ID: <064.31342ef44d3778f7bf01b8f0bc3c8ae6@haskell.org> #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows -------------------------------------+------------------------------------- Reporter: cromachina | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #16057 Comment: I think this is #16057 You should use 8.6.2 for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:17:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:17:33 -0000 Subject: [GHC] #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows In-Reply-To: <049.5f62cbbe05a855c9491b690e69a87da5@haskell.org> References: <049.5f62cbbe05a855c9491b690e69a87da5@haskell.org> Message-ID: <064.b09cafdeac4c741419428e5029a0f844@haskell.org> #16207: GHC 8.6.3 hangs building wreq-0.5.3.1 on Windows -------------------------------------+------------------------------------- Reporter: cromachina | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Thanks for the bug report. This is a duplicate of #16057, which will be addressed in GHC 8.6.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:35:45 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:35:45 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.432ebbecc95bc2a64e7a5604ec8cea45@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by artempyanykh): FWIW, `map.ll` needs to be compiled with `-mcpu=sandybridge`. Otherwise on Haswell the compiler emits `vbroadcastss` instead of `vmovaps` and the issue doesn't manifest itself. ----- I'm currently figuring out Mach-O part. I've adjusted section placement on x86_64 analogous to aarch64, but it's not enough as current x86_64 relocation code works directly with macho_sections. I need to take a closer look at it. I have concerns re: allocating a page per section. It seems feasible do some prep work before `ocGetNames` to calculate the size of future r-x segment and rw- segment and exact placement of sections inside the mmaped areas (although, currently not sure about subsequent changes to mprotecting and unloading code). Oh, and If somebody's already working on this, please let me know :) ---- One question, if I may. Moritz, for iOS you use regular `mmap` instead of `mmapForLinker`. I don't know much about ARM and wonder if allocating in low 2GB is not necessary there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:38:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:38:00 -0000 Subject: [GHC] #16173: Move `Data.Profunctor` from `profunctors` package to `base` In-Reply-To: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> References: <047.6810cf34cc660b5d49b4e80b5e00c886@haskell.org> Message-ID: <062.58672a959f9227a8c73af964c87491c4@haskell.org> #16173: Move `Data.Profunctor` from `profunctors` package to `base` -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: base, | profunctor, QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14767 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): If is it decided that `Profunctor` should use `QuantifiedConstraints` to get its `Functor` superclass, that would need to happen in library-space, not as it's moving into `base`. Aside from that, I don't feel particularly strongly about the superclass one way or the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 14:59:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 14:59:55 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.7cc86db7978f6dd5e2e27ccb3db233fc@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15437 Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I have a patch which fixes the issue presented in this ticket but there are some rough edges and design considerations which need to be dealt with. https://gitlab.haskell.org/ghc/ghc/merge_requests/166 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 16:10:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 16:10:22 -0000 Subject: [GHC] #16208: map/coerce does not fire with all newtypes Message-ID: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider a slightly modified version of T2110, compiled with -O: {{{ #!haskell {-# LANGUAGE GADTs #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} import GHC.Exts import Unsafe.Coerce newtype Age a b where Age :: forall a b. Int -> Age a b foo :: [Int] -> [Int] foo = map id fooAge :: [Int] -> [Age a b] fooAge = map Age fooCoerce :: [Int] -> [Age a b] fooCoerce = map coerce fooUnsafeCoerce :: [Int] -> [Age a b] fooUnsafeCoerce = map unsafeCoerce same :: a -> b -> IO () same x y = case reallyUnsafePtrEquality# (unsafeCoerce x) y of 1# -> putStrLn "yes" _ -> putStrLn "no" main = do let l = [1,2,3] same (foo l) l same (fooAge l) l same (fooCoerce l) l same (fooUnsafeCoerce l) l }}} This code correctly prints "yes" four times, as required by #2110. However, changing the order of type arguments in the definition of Age to: {{{ Age :: forall b a. Int -> Age a b }}} causes the test to fail in one case: `map Age` is no longer simplified to `Age`. The reason is that this change causes the newtype `Age` to have a wrapper, and the map/coerce rule is not detecting it (see Note [Getting the map/coerce RULE to work] and Note [Data con wrappers and GADT syntax]) This ticket is a prerequisite to linear types (since in linear types, all newtypes have wrappers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 16:33:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 16:33:11 -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.cd35b7d386e59d4d4ed658ce5d44bafc@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 16:38:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 16:38:40 -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.2c75e5f1ec5f4bfd1a2603e681784c3e@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by explicitcall): * cc: explicitcall@… (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 16:50:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 16:50:41 -0000 Subject: [GHC] #16209: GHC behaves differently when binding has separate or inlined type declaration Message-ID: <050.a40210ddae11435e1be0509e4f50da06@haskell.org> #16209: GHC behaves differently when binding has separate or inlined type declaration -------------------------------------+------------------------------------- Reporter: fghibellini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () = a putStrLn "success" }}} fails with: {{{ source_file.hs:6:44: Couldn't match expected type ‘forall (u :: * -> *). Functor u => u ()’ with actual type ‘t0 ()’ When checking that: t0 () is more polymorphic than: forall (u :: * -> *). Functor u => u () In the expression: a }}} but the following compiles successfully {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} On GHC 7.10 it works as described above. On newer ones it fails even on the "functioning code". {{{ a.hs:5:44: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: forall (t :: * -> *). Functor t => t () GHC doesn't yet support impredicative polymorphism • In the expression: undefined In a pattern binding: a :: forall (t :: * -> *). Functor t => t () = undefined In the expression: do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 16:51:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 16:51:54 -0000 Subject: [GHC] #16209: GHC behaves differently when binding has separate or inlined type declaration In-Reply-To: <050.a40210ddae11435e1be0509e4f50da06@haskell.org> References: <050.a40210ddae11435e1be0509e4f50da06@haskell.org> Message-ID: <065.d00aae5937244b5db3dc244102e44840@haskell.org> #16209: GHC behaves differently when binding has separate or inlined type declaration -------------------------------------+------------------------------------- Reporter: fghibellini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by fghibellini: Old description: > {{{#!hs > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > > main = do > let a :: forall t. Functor t => t () = undefined > let g :: forall u. Functor u => u () = a > putStrLn "success" > }}} > > fails with: > > {{{ > source_file.hs:6:44: > Couldn't match expected type ‘forall (u :: * -> *). > Functor u => > u ()’ > with actual type ‘t0 ()’ > When checking that: t0 () > is more polymorphic than: forall (u :: * -> *). Functor u => u () > In the expression: a > }}} > > but the following compiles successfully > > {{{#!hs > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > > main = do > let a :: forall t. Functor t => t () = undefined > let g :: forall u. Functor u => u () > g = a > putStrLn "success" > }}} > > On GHC 7.10 it works as described above. On newer ones it fails even on > the "functioning code". > > {{{ > a.hs:5:44: error: > • Cannot instantiate unification variable ‘a0’ > with a type involving foralls: > forall (t :: * -> *). Functor t => t () > GHC doesn't yet support impredicative polymorphism > • In the expression: undefined > In a pattern binding: > a :: forall (t :: * -> *). Functor t => t () = undefined > In the expression: > do let a :: forall t. Functor t => t () = undefined > let g :: forall u. Functor u => u () > g = a > putStrLn "success" > }}} New description: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () = a putStrLn "success" }}} fails with: {{{ source_file.hs:6:44: Couldn't match expected type ‘forall (u :: * -> *). Functor u => u ()’ with actual type ‘t0 ()’ When checking that: t0 () is more polymorphic than: forall (u :: * -> *). Functor u => u () In the expression: a }}} but the following compiles successfully {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} On GHC 7.10 it works as described above. On 8.4.4 it fails even on the "functioning code". {{{ a.hs:5:44: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: forall (t :: * -> *). Functor t => t () GHC doesn't yet support impredicative polymorphism • In the expression: undefined In a pattern binding: a :: forall (t :: * -> *). Functor t => t () = undefined In the expression: do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 17:13:37 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 17:13:37 -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.ca99f3f6e0cc78464ae094f5317352d1@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Would it be possible to generate the hs-boot file (or some equivalent) as a by-product of a module dependency analysis? E.g. {{{ module A where import B data Flip = MkFlip Flop flip :: Int -> Flip flip _ = MkFlip (flop []) module B where import A data Flop = MkFlop Flip flop :: [a] -> Flop flop _ = MkFlop (flip 42) }}} Dependency analysis based just on names finds out that `B` uses `A(Flip, flip)` and `A` uses `B(Flop, flop)`. The compiler could then pick one of (see below) the two modules and generate the hs-boot file: {{{ module A where data Flip flip :: Int -> Flip }}} This has the advantage of keeping the current model of separate compilation instead of starting to merge huge SCCs of the dependency graph into one module that takes eons to compile. I'm not sure if Haskell projects would be affected by the same trend, but large Java projects tend to have SCCs comprised of [https://link.springer.com/article/10.1007/s10664-006-9033-1 hundreds, if not thousands of files]. Of course, I just hand-waved over many technical challenges in my proposal above. I'm pretty certain the above approach would need actual involvement from the type-checker in complicated cases. I don't dare to think about handling type families this way, but wouldn't a name resolution approach get rid of 90% of the cases where we would need hs-boot files? Note that the compiler can still yell at you if it doesn't find a proper solution, or a solution that would involve the type-checker. Imagine that we didn't provide a type signature for `flip` or for `flop`. The above idea would not be able to synthesize the boot file for either `A` or `B`, because it doesn't do actual type-checking across modules. I imagine an error like: {{{ Couldn't infer any type of recursive group {A.flip, B.flop} Provide type signatures or an hs-boot file for any of the occuring modules to fix this. }}} Note that if we only leave out the type signature of `flip`, we still have enough information to compute the hs-boot file for `B` instead of `A`. In general, deciding which module to generate the boot file for could take other criteria, like minimality, into account. We could also have a look at how the D language does things, which has both strong meta-programming capabilities and allows circular module dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 17:15:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 17:15:07 -0000 Subject: [GHC] #16210: Hadrian devel2 flavour builds profiling way Message-ID: <049.3cb854d79d59d174586568a12c4e09ce@haskell.org> #16210: Hadrian devel2 flavour builds profiling way -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the make build system `devel2` doesn't build profiled libraries but hadrian does. This makes the build quite a lot slower. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 17:22:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 17:22:42 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance Message-ID: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program compiles without error using cabal. {{{ import Bar main :: IO () main = do let x = True -- line 5 --x <- True -- line 6 foo x bar foo :: Bool -> IO () -> IO () foo _ _ = undefined }}} However: 1. `cabal build`. This succeeds. [This step isn't required to reproduce the bug, but it shows that the program should compile.] 2. Replace line 5 with line 6 in Main.hs 3. `cabal build`. GHC correctly reports a compile error (`Couldn't match expected type 'IO Bool' with actual type 'Bool'`) 4. Fix the problem by reinstating line 5 and removing line 6. 5. `cabal build`. This step *should* compile without errors, but instead I get a GHC error about a missing instance related to the `monad-classes` library. 6. `cabal build` all day. The `missing instance` error still occurs until you clean temporary files and start from scratch. I suspect the error in step 5 is itself a (different?) GHC bug, but for now it is reported [https://github.com/strake/monad-classes.hs/issues/4 here]. This GHC bug report is specifically about compiling with identical source code (steps 1 and 5) and getting different outcomes (step 1 compiles, step 5 has an error), which shouldn't happen regardless of other bugs. [Note I can produce the `missing instance` issue without having to recompile GHC, which is why I think it might be independent of this bug.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 17:22:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 17:22:59 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance In-Reply-To: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> References: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> Message-ID: <062.8be7292323fdd8aa7d455d44fed74f3a@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "bug.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 19:17:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 19:17:58 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.a9c67b61e7210f4c0ded865f15172900@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Does the testsuite not support parallel build? The testsuite does support parallel execution. However, to enable parallel execution you must use the `THREADS` variable. For instance, {{{ make test THREADS=9 }}} For details see wiki:Building/RunningTests/Running. > It used to work without issue in previous versions, such 8.4.4. I'll admit I'm a bit skeptical; GHC's testsuite driver has never supported parallel execution using `make -j` as far as I know. Perhaps it didn't break as violently, but it certainly never worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 19:23:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 19:23:33 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.a872f975bf9dc173a1cfd2e7cadfa228@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Without parallel build, the testsuite still fails: Indeed `ghci063` is a known issue. See #16201. As far as the others are concerned: `T12752` is odd but smells of a broken toolchain (CPP is expected to throw an error on this test due to `-Wcpp- undef`). The rest are performance tests which indeed may vary from machine to machine (see #12758 which improves this situation in `master`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 19:26:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 19:26:06 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.44468dd8990dbf5ac32d2f278665cf25@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fxcoudert): Until now, the testsuite used to pass cleanly on all releases we shipped. Given that it's not the case any more, I am removing the testsuite entirely from the Homebrew build and test process. We'll just hope that the checks performed during your QC cycles on macOS are sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 20:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 20:50:59 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.f55a8067a8f179664a5fcb936c52004e@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Even only having CPR analysis (and not demand analysis) working with `UnboxedSums` is rather useful to me. I have some libraries where several functions look like this: {{{ data MyExceptionType = ... -- many constructors foo :: Int -> Int -> IO (Either MyExceptionType Int) }}} Crucially, `foo` is to large to inline, and I expect that the user is going to case on the result immediately (directly or by using something than inlines like `either`). If Phab:D2436 is correct, I'd be happy to rebase it and stick it behind a flag (maybe `-fcpr-small-sums`) that would cause this to happen for types with three or fewer data constructors (so `MyExceptionType` above doesn't get worker-wrappered). Hopefully, I could get this core: {{{ foo :: Int -> Int -> IO (Either MyExceptionType Int) fooInner :: Int# -> Int# -> State# RealWorld -> (# State# RealWorld, (# MyExceptionType | Int# #) #) }}} Since this does not reduce allocations in general, it has to be behind a flag. I don't know what a good name would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 20:52:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 20:52:11 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl Message-ID: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the file {{{#!hs module ClassParens where class LiftingMonad (trans :: MTrans) where proof :: Monad m :- Monad (trans m) class LiftingMonad2 ((trans :: MTrans)) where proof :: Monad m :- Monad (trans m) }}} The parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span. An annotation must always be within the span it is contained in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 20:52:27 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 20:52:27 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.06ef5c44fcf92623dc47f77e8401e88c@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 21:17:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 21:17:10 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.35bb38170edfb55b2af286e4238ece90@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): > I have just (2015/03/03) written a shell script (attached) that tests for binutils support for 64 bit pc-relative relocatons. > The test passes on *all* modern linux systems, but fails on Mac OSX (Mavericks) and OpenBSD 5.5 (current is 5.6). The failure is one OpenBSD says: According to https://www.openbsd.org/58.html, since OpenBSD 5.8 (2015-10-18), binutils have been upgraded to 2.17. > OSX has the linker from LLVM which theoretically could be fixed. LLD handles them since 2015-02-24 (https://reviews.llvm.org/rL230465). First release containing the patch: 3.7 (2015-09-01). Maybe we should revisit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 21:25:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 21:25:54 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.006df83c3fdd3892b442c03f17d32fff@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've discovered a way to work around the issue in comment:18. This is the instance we are trying to write: {{{#!hs class (forall b. Show b => Show (T a b)) => C a where type family T a :: * -> * }}} This doesn't work because the head of that quantified constraint mentions `T`, which is a type family. The normal trick is to add an extra constraint `ta ~ T a` and change the head of the quantified constraint to `Show (ta b)`. But where do we quantify `ta`? The answer to this question eluded me for the longest time, but it turns out the answer is shockingly simple: just quantify `ta` in the quantified constraint itself! That is to say, just do this: {{{#!hs class (forall ta b. (ta ~ T a, Show b) => Show (ta b)) => C a where type family T a :: * -> * }}} That's it! Now the instance typechecks, just like we've always dreamed of. I've tried this trick out on a large codebase that makes heavy use of quantified superclasses of this form, and it appears to work remarkably well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 21:29:24 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 21:29:24 -0000 Subject: [GHC] #16123: QuantifiedConstraints fails to deduce trivial constraint In-Reply-To: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> References: <047.1518eaf2076c4350235ef95f443815a1@haskell.org> Message-ID: <062.a4e51f1b847643b4b5bed52c8c80ff73@haskell.org> #16123: QuantifiedConstraints fails to deduce trivial constraint -------------------------------------+------------------------------------- Reporter: eschnett | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14680 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, I think I've discovered a way to work around this issue after all. I've written up the trick in full detail [https://ghc.haskell.org/trac/ghc/ticket/14860#comment:23 here], but in the particular case of your program, the trick is to redefine `Ok` slightly: {{{#!hs type Ok k :: ObjKind -> Constraint }}} Once you've done that, you can get the desired superclass for `Functor` if you write it like this: {{{#!hs class ( Category (Dom f), Category (Cod f) -- | Prove that this functor maps from its domain to its codomain , forall okCodF a. (okCodF ~ Ok (Cod f), Ok (Dom f) a) => okCodF (f a) ) => Functor f where }}} If you do this, then the rest of the module typechecks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 21:39:43 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 21:39:43 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.387f153342ef11ed06e6c07d01510ad7@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. Well, please note that this quantified constraint will fire on a constraint like `Show (Maybe Int)` Why? Because we can instantiate `Show (ta b)` to give `(Show (Maybe Int)`. So the quantified constraint overlaps with the top-level instance; but quantified constraints are tried (currently) before top-level instances, so the quantified constraint will "win". That might lead you to try to solve `(Maybe ~ T a)` which will probably fail. Perhaps in the applications you have in mind this will be fine. And if so, that's great. But I just wanted to point out that there might be unintended consequence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 21:58:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 21:58:58 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.c70d79104950252a38843c78f97bd45b@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: sgraf (added) Comment: Sebastian is working in this territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:00:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:00:11 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.fe9d0d9c3f65269af764c92fb32fd537@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | CPRAnalysis, DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: UnboxedSums => UnboxedSums, CPRAnalysis, DemandAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:23:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:23:15 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.970eced573de531e4f577be54f6abde2@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * status: new => closed * resolution: => fixed Comment: jackkelly, when josef wrote “latest GHC”, he probably meant HEAD, not the latest released version. This really works as expected with HEAD. It would be interesting to find out which commit fixed it. I tried ti `git bisect` but submodules don't cooperate with me (unsurprisingly). I got: {{{ fatal: repository '../hadrian.git' does not exist }}} I tried various combinations of `make clean` / `boot-configure` / `git submodules update --recursive`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:35:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:35:09 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance In-Reply-To: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> References: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> Message-ID: <062.e183f7bfddde0c09824ded6e8fe14a4b@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I had a quick go to reproduce, but failed to install `monad-classes`, thus {{{ /c/tmp/T16211$ cabal install monad-classes Warning: The package list for 'hackage.haskell.org' is 292 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Downloading base-orphans-0.7... Downloading peano-0.1.0.1... Downloading reflection-2.1.3... Configuring base-orphans-0.7... Building base-orphans-0.7... Downloading transformers-compat-0.6.1.6... Configuring peano-0.1.0.1... Configuring reflection-2.1.3... Configuring transformers-compat-0.6.1.6... Installed base-orphans-0.7 Building peano-0.1.0.1... Building reflection-2.1.3... Building transformers-compat-0.6.1.6... Installed peano-0.1.0.1 Installed transformers-compat-0.6.1.6 Downloading transformers-base-0.4.5.2... Downloading mmorph-1.1.2... Configuring mmorph-1.1.2... Installed reflection-2.1.3 Configuring transformers-base-0.4.5.2... Building mmorph-1.1.2... Building transformers-base-0.4.5.2... Installed transformers-base-0.4.5.2 Downloading monad-control-1.0.2.3... Configuring monad-control-1.0.2.3... Installed mmorph-1.1.2 Building monad-control-1.0.2.3... Installed monad-control-1.0.2.3 Downloading monad-classes-0.3.2.0... Configuring monad-classes-0.3.2.0... Building monad-classes-0.3.2.0... Failed to install monad-classes-0.3.2.0 Build log ( C:\Users\simonpj\AppData\Roaming\cabal\logs\ghc-8.4.3\monad- classes-0.3.2.0-8KgSrx1uXAE2nRQBG2VUas.log ): Preprocessing library for monad-classes-0.3.2.0.. Building library for monad-classes-0.3.2.0.. [ 1 of 12] Compiling Control.Monad.Classes.Core ( Control\Monad\Classes\Core.hs, dist\build\Control\Monad\Classes\Core.o ) [ 2 of 12] Compiling Control.Monad.Classes.Effects ( Control\Monad\Classes\Effects.hs, dist\build\Control\Monad\Classes\Effects.o ) [ 3 of 12] Compiling Control.Monad.Classes.Except ( Control\Monad\Classes\Except.hs, dist\build\Control\Monad\Classes\Except.o ) [ 4 of 12] Compiling Control.Monad.Classes.Exec ( Control\Monad\Classes\Exec.hs, dist\build\Control\Monad\Classes\Exec.o ) [ 5 of 12] Compiling Control.Monad.Classes.Proxied ( Control\Monad\Classes\Proxied.hs, dist\build\Control\Monad\Classes\Proxied.o ) [ 6 of 12] Compiling Control.Monad.Classes.Reader ( Control\Monad\Classes\Reader.hs, dist\build\Control\Monad\Classes\Reader.o ) [ 7 of 12] Compiling Control.Monad.Classes.State ( Control\Monad\Classes\State.hs, dist\build\Control\Monad\Classes\State.o ) [ 8 of 12] Compiling Control.Monad.Classes.ReadState ( Control\Monad\Classes\ReadState.hs, dist\build\Control\Monad\Classes\ReadState.o ) Control\Monad\Classes\ReadState.hs:42:8: error: * Type indexes must match class instance head Expected: StT (ReadStateT x) Actual: StT (ReadStateT s) a where the `' arguments are type variables, distinct from each other and from the instance variables * In the type instance declaration for `StT' In the instance declaration for `MonadTransControl (ReadStateT x)' | 42 | type StT (ReadStateT s) a = StT IdentityT a | ^^^ cabal: Leaving directory 'C:\Users\simonpj\AppData\Local\Temp\cabal- tmp-19032\monad-classes-0.3.2.0' cabal.exe: Error: some packages failed to install: monad-classes-0.3.2.0-8KgSrx1uXAE2nRQBG2VUas failed during the building phase. The exception was: ExitFailure 1 }}} This is with {{{ /c/tmp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3 /c/tmp$ cabal --version cabal-install version 2.2.0.0 compiled using version 2.2.0.1 of the Cabal library }}} I have not investigated further, thus far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:40:53 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:40:53 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance In-Reply-To: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> References: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> Message-ID: <062.905fef336cac7fa40a5633b047813213@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Thanks for looking, Simon. Unfortunately, I was unable to further minimize the example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:41:49 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:41:49 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.65759fbce713f244b1442b338dcd0f1a@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Maybe we should revisit? It sounds like we should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 22:50:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 22:50:39 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance In-Reply-To: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> References: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> Message-ID: <062.f5d13e718ee40cfabda7c56d297aacb1@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But you are getting further than me. I never got to compile your code even once, because I couldn't install `monad-classes`. (Obviously you were.) Maybe someone can figure out why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 21 23:28:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Jan 2019 23:28:19 -0000 Subject: [GHC] #16211: Recompiling results in a missing instance In-Reply-To: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> References: <047.a8e5ac16bc10cd1819380d2acd5df296@haskell.org> Message-ID: <062.6133d2c5e1ba506633abd5cfbf293cb7@haskell.org> #16211: Recompiling results in a missing instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Simon, it looks like you have a pretty outdated Hackage snapshot. Perhaps try a `cabal update`? The latest version of monad-classes is 0.3.2.2, but your failed installation was trying 0.3.2.0. {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 > cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library > cd bug > cabal sandbox init > cabal install --only-dependencies Starting peano-0.1.0.1 Starting base-orphans-0.8 Starting reflection-2.1.4 Starting primitive-0.6.4.0 Building base-orphans-0.8 Building reflection-2.1.4 Building primitive-0.6.4.0 Building peano-0.1.0.1 Completed base-orphans-0.8 Starting transformers-compat-0.6.2 Completed peano-0.1.0.1 Building transformers-compat-0.6.2 Completed reflection-2.1.4 Completed transformers-compat-0.6.2 Starting mmorph-1.1.2 Starting transformers-base-0.4.5.2 Building transformers-base-0.4.5.2 Building mmorph-1.1.2 Completed transformers-base-0.4.5.2 Starting monad-control-1.0.2.3 Completed mmorph-1.1.2 Completed primitive-0.6.4.0 Building monad-control-1.0.2.3 Completed monad-control-1.0.2.3 Starting monad-classes-0.3.2.2 Building monad-classes-0.3.2.2 Completed monad-classes-0.3.2.2 > cabal build }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 00:31:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 00:31:08 -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.3c046023ff699781e8492f336366a371@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: AndreasK (added) Comment: For cases where branch prediction is impossible this makes quite the difference in my experience. I have some proof of concept code for Int/Word already. I plan to keep the branch [here](https://github.com/AndreasPK/ghc/tree/minmax) updated until I got a patch ready. If someone feels like taking this over contact me, otherwise I will probably put up a patch for the Int/Word in a month or two depending on how time I can spend on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 02:14:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 02:14:28 -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.d488f5b5ae92c95f53bac31796a790ef@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by atravers): So there's still some interest after all. I had thought about providing some details about my prototype implementation (e.g. how it avoids the "all-in-one" approach) but having read [a draft of] the Melton-Tempero paper (and various others over the break) I now pause to consider a question: ''Are recursive imports taking recursion a step too far?'' To use a automotive analogy - oil works well for certain parts of the typical car (e.g. engine and gearbox) but that doesn't mean oil would work just as well for other parts of the car (e.g. brakes and clutches). With 2020 on the horizon, and drawing some inspiration from a few of those other papers (and, well, Douglas Adams), I now suggest the following: 1. Support for recursive imports be **withdrawn** from the new Haskell 2020 standard; 2. A new proposal for recursive imports be added to the Haskell-proposals page of the Haskell wiki site, where a concise description can be made along with a list of subsequent problems, for the intrepid to find solutions to. 3. If those solutions are viable, then recursive imports would be reinstated in a post-2020 Haskell standard. The intent is that the proposal-page be ''the'' central point of reference for everything related to implementing recursive imports instead of being scattered far and wide as it is now - a veritable clearing-house for old and new ideas and suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 06:31:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 06:31:44 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.991161a8432c0cc2174408c99a02f975@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gander): * owner: gander => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 09:40:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 09:40:28 -0000 Subject: [GHC] #16213: Unnecessary error Message-ID: <049.d570e9e2d8db590facfbba25ee4ee5f9@haskell.org> #16213: Unnecessary error -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know whether this is a bug or a feature request.... When compiling {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module Main where data Term (b::Bool) where Const :: Int -> Term 'True Sum :: --Show (TermList v) => TermList v -> Term 'False instance Show (Term b) where show (Const a) = "(Const " ++ show a ++ ")" show (Sum a) = "(Sum " ++ show a ++ ")" data TermList (xs :: [ Bool ]) where TNil :: TermList '[] TCons :: Term x -> TermList xs -> TermList (x ': xs) instance Show (TermList '[]) where show TNil = "Nil" instance Show (TermList xs) => Show (TermList (x ': xs)) where show (TCons a b) = "(Cons " ++ show a ++ " " ++ show b ++ ")" main :: IO () main = do putStrLn "Hello world!" }}} one gets the error {{{ src\Main.hs:37:31: error: * Could not deduce (Show (TermList v)) arising from a use of `show' from the context: b ~ 'False bound by a pattern with constructor: Sum :: forall (v :: [Bool]). TermList v -> Term 'False, in an equation for `show' at src\Main.hs:37:11-15 * In the first argument of `(++)', namely `show a' In the second argument of `(++)', namely `show a ++ ")"' In the expression: "(Sum " ++ show a ++ ")" | 37 | show (Sum a) = "(Sum " ++ show a ++ ")" | ^^^^^^ }}} Yet, both patterns are matched, i.e. '[] and (x ': xs), so I was surprised the compiler could not figure this out! By out commenting 'Show (TermList v) => ' the code complies fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 10:53:36 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 10:53:36 -0000 Subject: [GHC] #16214: Hadrian prof flavour doesn't build a compiler which you can profile Message-ID: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> #16214: Hadrian prof flavour doesn't build a compiler which you can profile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building a compiler with the `prof` flavour. I tried to use it with the `-xc` option. {{{ ./hadrian/build.sh --flavour=prof _build/stage1/bin/ghc A.hs +RTS -xc }}} But apparently {{{ ghc: the flag -xc requires the program to be built with -prof }}} So it seems that the `prof` flavour is broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 11:05:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 11:05:48 -0000 Subject: [GHC] #16214: Hadrian prof flavour doesn't build a compiler which you can profile In-Reply-To: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> References: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> Message-ID: <064.bd247eb843377cd656eb16cc51965562@haskell.org> #16214: Hadrian prof flavour doesn't build a compiler which you can profile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The place where this logic is implemented is `programContext` but `programContext` is always immediately passed to `programPath` which ignores anything about the ways so no wonder this doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 11:47:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 11:47:16 -0000 Subject: [GHC] #16215: Refactor getProgramContext in Hadrian Message-ID: <049.810e079cc16d55cd597ffaca1c1b9c08@haskell.org> #16215: Refactor getProgramContext in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- All the calls to `getProgramContext` in Hadrian are immediately passed to `programPath` so to avoid confusion the two functions should probably be combined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 11:57:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 11:57:19 -0000 Subject: [GHC] #16216: readHexRational missing from Numeric Message-ID: <045.c5090807f6ac2e49f2a7ca86acd5fa4d@haskell.org> #16216: readHexRational missing from Numeric -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The HexFloatLiterals extension was merged as result of https://github.com /ghc-proposals/ghc-proposals/blob/master/proposals/0004-hexFloats.rst As part of this proposal `showHFloat` was added to Numeric to output floating points in hexFloat format, unfortunately, no one seems to have remembered to add `readHexRational` or a similar function to parse hexFloats to Numeric. This leads to the awkward scenario that I can easily produce hexFloat values, but have no way to parse them from `String`/`Text` data... All the code already exists in `compiler/util/Utils.hs`, someone just needs to cherry pick the implementation add add it to Numeric in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 12:20:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 12:20:50 -0000 Subject: [GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP In-Reply-To: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> References: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> Message-ID: <062.971ae8d287b3f651fa09276194eb1d2f@haskell.org> #16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.6.2 Resolution: | Keywords: Applicative, | Parsers, ReadP Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dbaynard): This is currently blocked on a decision (from the core libraries committee?) on how to proceed — either to take it up (and begin the deprecation process for `optional`, to propose a way to take it to the wider community (a process I'm happy to lead), or to dismiss as wontfix. Whatever the case, I would like to begin the process as soon as possible; perhaps even beginning deprecation in the next major release. It seems like this would languish here, otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 12:44:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 12:44:12 -0000 Subject: [GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP In-Reply-To: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> References: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> Message-ID: <062.dca80df6071cc522d1589844db58d1b6@haskell.org> #16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.6.2 Resolution: | Keywords: Applicative, | Parsers, ReadP Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It isn't really clear what the advantage here is to deprecating this function. There is the clear disadvantage that it will break people's programs which use it. Does anyone feel the pain of this inconsistency? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 12:47:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 12:47:02 -0000 Subject: [GHC] #16214: Hadrian prof flavour doesn't build a compiler which you can profile In-Reply-To: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> References: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> Message-ID: <064.06db6b423d6633be3cfd3e5a7ae14727@haskell.org> #16214: Hadrian prof flavour doesn't build a compiler which you can profile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/179 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 13:10:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 13:10:23 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.a4c016f942d47c6e9b10d1757a9d4596@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): @artempyanykh, sorry for the late reply, I've been way too busy the last day. On iOS we don't have largeAddressSpace, and I doubt we have any issues with address allocation. I don't remember exactly why I didn't use `mmapForLinker`. But I *do* remember trying to use it and running into some issues where making using `mmapForLinker` work for iOS as well would have unnecessarily complicated and such just went for `mmap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 13:30:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 13:30:46 -0000 Subject: [GHC] #16209: GHC behaves differently when binding has separate or inlined type declaration In-Reply-To: <050.a40210ddae11435e1be0509e4f50da06@haskell.org> References: <050.a40210ddae11435e1be0509e4f50da06@haskell.org> Message-ID: <065.3c93b0cdb978880b845b4a0a9c5db5a8@haskell.org> #16209: GHC behaves differently when binding has separate or inlined type declaration -------------------------------------+------------------------------------- Reporter: fghibellini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): See further discussion on [https://stackoverflow.com/q/54293485/791604 StackOverflow]. Executive summary of my thoughts there: 7.10.3 is correct to disallow the first program, and buggy because it allows the second program; meanwhile, modern GHC correctly disallows both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 14:04:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 14:04:32 -0000 Subject: [GHC] #16213: Unnecessary error In-Reply-To: <049.d570e9e2d8db590facfbba25ee4ee5f9@haskell.org> References: <049.d570e9e2d8db590facfbba25ee4ee5f9@haskell.org> Message-ID: <064.b46f7afaeb3c5a4668e144df1ee5c7a7@haskell.org> #16213: Unnecessary error -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [ticket:16213 pjljvdlaar]: > Yet, both patterns are matched, i.e. '[] and (x ': xs), > so I was surprised the compiler could not figure this out! This isn't how type class instances work. Having an `Show (TermList '[])` instance and a `Show (TermList (x ': xs))` instance doesn't imply an instance for `forall (v :: [Bool]). Show (TermList v)`. In the instance you're trying to write, GHC needs a `Show` instance for an arbitrary list `v`, and GHC can't know //a priori// whether that list is `'[]` or `(_ ': _)`. That being said, there's not much sense in writing two separate `Show` instances like this. Why not just combine them into a single instance, like so? {{{#!hs instance Show (TermList v) where show TNil = "Nil" show (TCons a b) = "(Cons " ++ show a ++ " " ++ show b ++ ")" }}} This actually gives you an instance for `forall (v :: [Bool]). Show (TermList v)`, so you avoid your earlier issue entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 14:04:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 14:04:59 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.46c8700fb60e0c04e6ae56d38b7e6ee4@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.4 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16141 Blocked By: | Blocking: Related Tickets: #16191 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"a5373c1fe172dee31e07bcb7c7f6caff1035e6ba/ghc" a5373c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5373c1fe172dee31e07bcb7c7f6caff1035e6ba" Fix bogus worker for newtypes The "worker" for a newtype is actually a function with a small (compulsory) unfolding, namely a cast. But the construction of this function was plain wrong for newtype /instances/; it cast the arguemnt to the family type rather than the representation type. This never actually bit us because, in the case of a family instance, we immediately cast the result to the family type. So we get \x. (x |> co1) |> co2 where the compositio of co1 and co2 is ill-kinded. However the optimiser (even the simple optimiser) just collapsed those casts, ignoring the mis-match in the middle, so we never saw the problem. Trac #16191 is indeed a dup of #16141; but the resaon these tickets produce Lint errors is not the unnecessary forcing; it's because of the ill-typed casts. This patch fixes the ill-typed casts, properly. I can't see a way to trigger an actual failure prior to this patch, but it's still wrong wrong wrong to have ill-typed casts, so better to get rid of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 14:04:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 14:04:59 -0000 Subject: [GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) In-Reply-To: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> References: <047.399f4846362801b97ea6d55afe6ae7d2@haskell.org> Message-ID: <062.4c5de056dd6b4b6a8b16a58676052df9@haskell.org> #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"a5373c1fe172dee31e07bcb7c7f6caff1035e6ba/ghc" a5373c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5373c1fe172dee31e07bcb7c7f6caff1035e6ba" Fix bogus worker for newtypes The "worker" for a newtype is actually a function with a small (compulsory) unfolding, namely a cast. But the construction of this function was plain wrong for newtype /instances/; it cast the arguemnt to the family type rather than the representation type. This never actually bit us because, in the case of a family instance, we immediately cast the result to the family type. So we get \x. (x |> co1) |> co2 where the compositio of co1 and co2 is ill-kinded. However the optimiser (even the simple optimiser) just collapsed those casts, ignoring the mis-match in the middle, so we never saw the problem. Trac #16191 is indeed a dup of #16141; but the resaon these tickets produce Lint errors is not the unnecessary forcing; it's because of the ill-typed casts. This patch fixes the ill-typed casts, properly. I can't see a way to trigger an actual failure prior to this patch, but it's still wrong wrong wrong to have ill-typed casts, so better to get rid of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 14:50:22 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 14:50:22 -0000 Subject: [GHC] #16216: readHexRational missing from Numeric In-Reply-To: <045.c5090807f6ac2e49f2a7ca86acd5fa4d@haskell.org> References: <045.c5090807f6ac2e49f2a7ca86acd5fa4d@haskell.org> Message-ID: <060.07bc173b1fc67e68cfed89a172a7b6a0@haskell.org> #16216: readHexRational missing from Numeric -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by merijn): As carter pointed out on IRC, (and asked me to echo here) this would also improve our IEEE754 compliance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 16:31:25 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 16:31:25 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.388bb5b91d0ae2ab9d1e67cebd274a33@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've added these cases to the testsuite in [[https://gitlab.haskell.org/ghc/ghc/merge_requests/185|!185]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 20:02:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 20:02:30 -0000 Subject: [GHC] #16217: check-api-annotations should check that an annotation does not precede its span Message-ID: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> #16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For an API annotation to be useful, it must not occur before the span it is enclosed in. So, for `check-api-annotation` output, a line such as {{{ ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]), }}} should be flagged as an error, as the `AnnOpenP` location of `3:21` precedes its enclosing span of `3:22-26`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 20:44:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 20:44:38 -0000 Subject: [GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) In-Reply-To: <048.c260191f02fda2523355325d46129a68@haskell.org> References: <048.c260191f02fda2523355325d46129a68@haskell.org> Message-ID: <063.a181ec5a80b0cc560fc14d05a9fdacdb@haskell.org> #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): fxcoudert, to be clear, I would love to understand `T12752` better but cannot reproduce it on our intrastructure. Can you describe your environment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:05:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:05:41 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.9902ae4fdbb6eda6ca2a0c8773111fd7@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: #16085 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): I have marked T1288_ghci as broken in !186. In my opinion we should mark the particularly fragile tests as broken in the unregisterised way. Not only will this help identify the tests which the unregisterised backend struggles with (which may help identify how it can be fixed) it also brings us closer to removing the `allow_failure` tag from the unregisterised CI job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:11:54 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:11:54 -0000 Subject: [GHC] #16147: ghc-pkg deadlocks on macOS In-Reply-To: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> References: <042.0220339b7ea7a70d4c682efb6100df55@haskell.org> Message-ID: <057.cd929380e99863bfc4e2b2d51872b921@haskell.org> #16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.4 Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 16147 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => infoneeded * milestone: => 8.6.4 Comment: That patch is now upstream; can someone check that it fixed the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:34:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:34:48 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.f35ca1bfc67c2d916a35c114af94702a@haskell.org> #16160: TH_NestedSplices fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * cc: Phyx- (added) Comment: Have you seen this before, Phyx? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:36:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:36:37 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it In-Reply-To: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> References: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> Message-ID: <062.b729d0822f04e464fc794df403e0db32@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: interpreter Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2996 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2996 * milestone: => 8.10.1 Comment: DemiMarie had a stab at this previously in Phab:D2996 but there was never a characterisation of whether the improve was worth the complexity. It would be great if you could pick it up again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:39:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:39:19 -0000 Subject: [GHC] #16155: Pattern Synonym for Ratio In-Reply-To: <045.ce08db94d22390d42df2c4c4a01fd23d@haskell.org> References: <045.ce08db94d22390d42df2c4c4a01fd23d@haskell.org> Message-ID: <060.8d6b2c5738815d7500effdcbbff14c9f@haskell.org> #16155: Pattern Synonym for Ratio -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: newcomer, | PatternSynonyms, Ratio Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: PatternSynonyms, Ratio => newcomer, PatternSynonyms, Ratio Comment: This sounds like a great idea but it would require changes to a library specified by the Report and consequently would require the approval of the [[https://wiki.haskell.org/Core_Libraries_Committee|Core Libraries Committee]]. Could you first bring this proposal to them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:43:55 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:43:55 -0000 Subject: [GHC] #16217: check-api-annotations should check that an annotation does not precede its span In-Reply-To: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> References: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> Message-ID: <059.6430e813925763ccb44fd8825d410aaf@haskell.org> #16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Merge request on gitlab: https://gitlab.haskell.org/ghc/ghc/merge_requests/190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:47:20 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:47:20 -0000 Subject: [GHC] #16149: GHC for NetBSD In-Reply-To: <042.ec25b766da631cfe6646ad0852f629a2@haskell.org> References: <042.ec25b766da631cfe6646ad0852f629a2@haskell.org> Message-ID: <057.810e72a81fa3fbca2fcf00b3e53c2b96@haskell.org> #16149: GHC for NetBSD ------------------------------------+-------------------------------------- Reporter: gh1 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: NetBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by bgamari): I don't know of description currently but it would be great if someone could step up to document the process on the Wiki. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:53:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:53:32 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.237a742a7180f9ef208df05c0882117f@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged with 9ea8dcea3e5ba96808ef91028e0efde9d31f7272. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:59:00 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:59:00 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.93111ab91ea021e7be9134963269a990@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Adding test in !192. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 21:59:43 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 21:59:43 -0000 Subject: [GHC] #16108: GHC --version doesn't show arch In-Reply-To: <046.5a6eb8c15e0de8070ae6c797522d328c@haskell.org> References: <046.5a6eb8c15e0de8070ae6c797522d328c@haskell.org> Message-ID: <061.03a8a724498ab90eeac2efd7aa8b8416@haskell.org> #16108: GHC --version doesn't show arch -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth, I suspect you could use `ghc --info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:01:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:01:08 -0000 Subject: [GHC] #16107: Update GCC compiler & friends In-Reply-To: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> References: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> Message-ID: <061.eda349a0c6e605dc6e8182b14bfb4814@haskell.org> #16107: Update GCC compiler & friends -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * milestone: => 8.10.1 Comment: CCing Tamar, our Windows czar. I'm not sure whether there is anything keeping us on the `gcc` release we use currently. Tamar, should I just go ahead and try updating it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:03:09 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:03:09 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.930487573aba068d22b824e6afff9b6b@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Would it be reasonable? Perhaps. Would it be easy to implement? I don't believe so. You would need to somehow walk the heap looking for references to freed interfaces so that they can be GC'd (or make any reference that might refer to something in another module weak, which would come at quite some cost). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:08:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:08:27 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? In-Reply-To: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> References: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> Message-ID: <061.607628d5f1cff0a5138bb99382e33346@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 (make) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:14:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:14:26 -0000 Subject: [GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. In-Reply-To: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> References: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> Message-ID: <060.ee466735bfa238c7e74152fef07c9eab@haskell.org> #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | getCurrentDirectory Blocked By: | Blocking: Related Tickets: #16080 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #16080 Comment: Hmm, this looks quite similar to #16080. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:14:43 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:14:43 -0000 Subject: [GHC] #16080: runTestTT from ghci caused a panic. In-Reply-To: <053.34b4d518efefb7683003b02513dac18d@haskell.org> References: <053.34b4d518efefb7683003b02513dac18d@haskell.org> Message-ID: <068.bc7813365f81bfb64f97c96dd3b4b88b@haskell.org> #16080: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: emacstheviking | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #16088 Comment: #16088 looks similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:15:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:15:16 -0000 Subject: [GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. In-Reply-To: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> References: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> Message-ID: <060.87b94326a6865641c87948e5d4ce11e7@haskell.org> #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | getCurrentDirectory Blocked By: | Blocking: Related Tickets: #16080 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Unfortunately I can't reproduce this. Do you observe this in `ghci` started from a normal shell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:17:58 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:17:58 -0000 Subject: [GHC] #15662: Line pragmas appear to be slightly broken with Clang's CPP In-Reply-To: <046.2a012973b0e74ae240426b655456015f@haskell.org> References: <046.2a012973b0e74ae240426b655456015f@haskell.org> Message-ID: <061.858e9ce9174a3abdb872c74f9f5dd416@haskell.org> #15662: Line pragmas appear to be slightly broken with Clang's CPP -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: For the record comment:2 removes the broken expectation from the relevant tests. However, this does mean that these tests will break on pre-Mojave `clang`s. To fix this we would need to add version probing logic to the testsuite which seems like a lot of work for this corner case. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:18:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:18:40 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.cdffe0cc4312099fa7680a14843ff6e7@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:19:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:19:30 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.f34b8264714c5b303d4e75024addc9ee@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15936 | Differential Rev(s): Phab:D3758, Wiki Page: | Phab:D5059 -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #15936 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:20:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:20:21 -0000 Subject: [GHC] #16003: Average and maximum residency numbers in nofib broken In-Reply-To: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> References: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> Message-ID: <059.3a8e26c5b007e08285af7b44d8eac799@haskell.org> #16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D5418 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:22:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:22:47 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.9daa50ca60ccb834c16ed3ae88cd8f1b@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): Right, but a Core Lint failure would tell us at compile-time whether and where the compiler misstepped. Sadly it looks like this won't be so simple to find. dnspies, any help you could provide in minimizing the reproducer would be greatly appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:33:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:33:11 -0000 Subject: [GHC] #15876: Function versioning instead of compilation flags... In-Reply-To: <050.687e46bbf749169d23d59f0ecea89286@haskell.org> References: <050.687e46bbf749169d23d59f0ecea89286@haskell.org> Message-ID: <065.73f10229710d98a55ea0458a9acdc2b8@haskell.org> #15876: Function versioning instead of compilation flags... -------------------------------------+------------------------------------- Reporter: MichalGajda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Linking) | Keywords: simd, Resolution: | flavors, speed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this is an intriguing opportunity. Perhaps you would like to give it a try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 22:39:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 22:39:38 -0000 Subject: [GHC] #16164: Provide bitreverse primop In-Reply-To: <047.f3aae0f1a192ff22dd51ddc4f1892d2e@haskell.org> References: <047.f3aae0f1a192ff22dd51ddc4f1892d2e@haskell.org> Message-ID: <062.2a756213cddaa4ee67c0f16e2959241f@haskell.org> #16164: Provide bitreverse primop -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: Indeed. This would be great to have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 23:32:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 23:32:45 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.7fa84635851c5ae0fedef25678643e69@haskell.org> #16160: TH_NestedSplices fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): No I haven't, that's new, from the look of it the stack frame is completely screwed up though. I can take a look at it this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 22 23:41:24 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Jan 2019 23:41:24 -0000 Subject: [GHC] #16107: Update GCC compiler & friends In-Reply-To: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> References: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> Message-ID: <061.c917ddc69f8b3cf2afeb7c6824acf1ff@haskell.org> #16107: Update GCC compiler & friends -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I've intentionally not updated them because mingw-w64 have not been able to release the 32-bit version of the toolchain due to a stage3 failure for GCC 8 and now 9. Originally no GCC 8 builds were available, I fixed this with upstream and the 64-bits were released but the 32-bit ones are still failing https://gcc.gnu.org/ml/gcc/2019-01/msg00178.html which is what I'm working on with upstream now. The problem is I don't particularly want a different toolchain and runtime for the 32-bit and 64-bit toolchains as it'll be confusing for the users but also we don't test the 32-bit ones often, so we'll likely to break it with a different toolchain. If we want to update before the tarballs are released by mingw-w64 we'll have to spin our own binaries disabling the ada bootstrap. the CRT I haven't updated due to a weird behavior with NaN and INF in a testcase, though that may have been fixed now. Haven't checked yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:00:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:00:00 -0000 Subject: [GHC] #16107: Update GCC compiler & friends In-Reply-To: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> References: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> Message-ID: <061.271e715c32374fe1d3b4764287b8f9e2@haskell.org> #16107: Update GCC compiler & friends -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Tamar would you prefer waiting with updating the other tools until the tarballs are released by mingw-w64 ? crt, winpthreads, headers, libwinpthread, zlib, isl, mpfr, gmp, binutils, libidn2, gcc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:00:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:00:05 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin Message-ID: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> #16218: T16180 is broken on Darwin ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Unfortunately the test `T16180` snuck in to the tree in with commit f035504b, just before I had a chance to merge !137, making Darwin a mandatory-green platform. Consequently we didn't catch that this test is broken on Darwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:00:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:00:54 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin In-Reply-To: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> References: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> Message-ID: <061.abd788d3d2488b7185e1d1bdb444e7d0@haskell.org> #16218: T16180 is broken on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * cc: hsyl20 (added) Comment: Henry, do you think you could have a look at this? Sadly the CPP you added didn't quite fix the issue (see https://gitlab.haskell.org/ghc/ghc/-/jobs/15667). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:06:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:06:42 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin In-Reply-To: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> References: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> Message-ID: <061.dfcb13a2723c8ca6109199dcaffa1be1@haskell.org> #16218: T16180 is broken on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Actually, I think I see an easy way to fix this. Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:10:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:10:35 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin In-Reply-To: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> References: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> Message-ID: <061.1ffed96bc8a799eaca0edcc80853c7d5@haskell.org> #16218: T16180 is broken on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/195 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/195 Comment: See !195. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 00:26:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 00:26:30 -0000 Subject: [GHC] #16107: Update GCC compiler & friends In-Reply-To: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> References: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> Message-ID: <061.313ef9aebb018603767976dc6404bf43@haskell.org> #16107: Update GCC compiler & friends -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): They can be updated and gcc to 7.4 since that's available for both. That said unless you're having a specific issue with the toolchain I doubt you'll see a difference. GCC backports are quite conservative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 04:45:29 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 04:45:29 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.8412da9ffb5b1b0a8cb01adaa49cd08c@haskell.org> #16160: TH_NestedSplices fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Hmm is this still failing on master? It doesn't show up for me. Only failures I see on x86_64 are {{{ hp2ps/T15904.run T15904 [bad exit code] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/base/tests/hWaitForInput-accurate-socket.run hWaitForInput- accurate-socket [exit code non-0] (normal) plugins/plugins09.run plugins09 [bad stdout] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp- impure [bad stdout] (normal) }}} of which `T15904` and `plugin-recomp-impure` seem to be testisms, `hWaitForInput-accurate-socket` seems broken? imports a missing module. The plugins however panic and `T10672_x64` is an atexit failure which I need to finish looking at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 05:02:27 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 05:02:27 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.90a01ab0c1d9449d18ef6fd20e6980a4@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a consequence of #16082. I do not see an easy solution that isn't ugly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 06:06:48 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 06:06:48 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error Message-ID: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Repro: https://github.com/LightAndLight/backpack-test I've been stuck on this for a while now. There's a weird interaction between the Template Haskell pragma and indefinite modules. When Template Haskell is enabled in this particular file (but TH features aren't used) I get an interface error. When I remove the pragma, the project successfully compiles. I hope I haven't made some trivial .cabal blunder. Anyway, I'm interested in potentially trying to fix this, but I've been digging around in GHC for a couple of days and figured it was time to ask for help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 06:49:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 06:49:47 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.d6ea6b152172cb40a6c046c12c91dd01@haskell.org> #16186: Segfault when embedding data via file-embed. -------------------------------------+------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): Replying to [comment:12 bgamari]: > syd, very interesting. Can you reproduce this with 8.6? If not, is it possible that you are running out of memory? This sounds very much like #14329 although I believe this was fixed in 8.4.3. I wasn't running out of memory, but I tried gain with 8.6.3 and the problem doesn't seem to exist anymore. I didn't try it out in entirely the same but now it works with stack and even `100MiB` of random data and that seems to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 08:18:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 08:18:35 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.afe2f427bb6bf58729466ae605e4bcb5@haskell.org> #16186: Segfault when embedding data via file-embed. -------------------------------------+------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): I just tried with 8.6.3 but via nix and that also works with `100MiB` now. So I'll close this here. Thanks for the help @bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 08:18:55 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 08:18:55 -0000 Subject: [GHC] #16186: Segfault when embedding data via file-embed. In-Reply-To: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> References: <042.f8b957cf9f13b9e121757bfb35d33016@haskell.org> Message-ID: <057.c1c17559194d829e8b4cd8a383c4046b@haskell.org> #16186: Segfault when embedding data via file-embed. -------------------------------------+------------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by syd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 08:19:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 08:19:52 -0000 Subject: [GHC] #16134: Continuous integration on FreeBSD In-Reply-To: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> References: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> Message-ID: <061.4f904981d1b9c32ca03aebd086b5469e@haskell.org> #16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 09:43:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 09:43:30 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.4108121f61d91c108aae13b882524d2e@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: (none) => josefs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 12:32:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 12:32:09 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.765cd24a85ffe2320f1937bdbb1924f7@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T15646 Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * testcase: => T15646 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 13:53:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 13:53:54 -0000 Subject: [GHC] #15470: Record projections with ambiguous types In-Reply-To: <047.3cdd34484629508fb5a4f38ac9554616@haskell.org> References: <047.3cdd34484629508fb5a4f38ac9554616@haskell.org> Message-ID: <062.7c72bc9c41100012441394132bc02600@haskell.org> #15470: Record projections with ambiguous types -------------------------------------+------------------------------------- Reporter: sweirich | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm a bit leery about changing the order of type variables just to support this one use case, especially since if we had the ability to bind type variables in lambdas, then we could implement these record projections without the need to change the original types: {{{#!hs type family F a data T a = MkT (forall a. F a) fld :: T -> (forall a. F a) fld (MkT x) = (\@a -> x @a) }}} Moreover, this type-variable-reordering hack really only works in one direction. That is to say, you can define record selectors since the position of the `forall` allows you to float those type variables to the front, but you can't define a synonym for the constructor itself, like so: {{{#!hs mkT :: (forall a. F a) -> T mkT = ??? }}} Here, we can't float the `a` to the front, so we're left without a way to implement this. With type variables in lambdas, we could, however: {{{#!hs mkT :: (forall a. F a) -> T mkT x = T (\@a -> x @a) }}} Of course, I'm speculating a bit here and assuming that the ambiguity check won't kick in on the examples above. (I have no way of knowing this, since type-variables-in-lambdas aren't yet implemented.) But it seems like it could be a viable alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 14:12:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 14:12:32 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.c9c1b5b96ee74e40bd1072c15f2bccf3@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, @josefs, for looking at this. Do you have an implementation plan in mind? I haven't looked at this beyond reading the ticket, but a solution that doesn't allow incorrect impredicativity looks subtle to design and implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 15:34:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 15:34:41 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.0a47b0cc1027daf18dd51368d3218771@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ezyang (added) Comment: Edward, do you think you could offer some insight here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 16:25:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 16:25:56 -0000 Subject: [GHC] #16220: -Wmissing-signatures should warn when top-level signature is partial Message-ID: <047.70a8a8f1d630aaa098c9ebe6acff83dd@haskell.org> #16220: -Wmissing-signatures should warn when top-level signature is partial -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd like GHC to emit a warning for the following definition: {{{#!hs g :: _ g = True }}} But not for that one: {{{#!hs f :: Int f = x where x :: _ x = 1 }}} The context is that I'm using partial signatures to help the type checker give the right type to a binding, with no intention of filling the holes later. (what Richard calls elision [https://github.com/ghc-proposals/ghc- proposals/pull/194 here]) The warning accompanying partial signatures (`-Wpartial-type-signatures`) effectively treats `_`-s in type signatures as holes which are meant to be filled (the type-level equivalent of typed holes). Which is not useful to my usage. I can deactivate `-Wpartial-type-signatures`, however, it seems to me that, in that case, a partial top-level signature is just as bad as a missing top-level signature. So it seems to me that whenever I have `-Wmissing-signatures` enabled I also want to warn for partial top-level signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 16:27:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 16:27:03 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.ba120ed3020b319f4838d212244873c0@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): I don't know whether the below observation is at all useful, but it seems that while let-bound polymorphism is restricted by ApplicativeDo, the same does not appear to be the case with "where". Thus changing the code as follows: {{{ main = do line <- getLine lock <- newMVar () - let locker :: Locker + go line lock + where + go line lock = + f line locker + where + locker :: Locker locker = withMVar lock . const - f line locker }}} makes the module compile. I don't know whether it is possible to perform that kind of transformation automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 17:11:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 17:11:10 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.c53688da706ceeb68913dcba4e634a4d@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yes, I plan to look into it. It may be related to https://github.com/haskell/cabal/issues/5634 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 17:47:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 17:47:13 -0000 Subject: [GHC] #16221: Core Lint error with a data type Message-ID: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following data declaration fails `-dcore-lint` {{{ #!haskell {-# LANGUAGE PolyKinds, ExplicitForAll, ExistentialQuantification #-} module T16221 where data T0 a = forall k (b :: k). MkT0 (T0 b) !Int }}} The test case was extracted from T14066a, the bang is to force the data type to have a wrapper. This has been present at least since GHC 8.0. {{{ : warning: In the type ‘T0 a_a1wY’ Kind application error in type ‘T0 a_a1wY’ Function kind = forall k. k -> * Arg kinds = [(k_X1x2, *), (a_a1wY, k_a1wZ)] Fun: k_X1x2 (a_a1wY, k_a1wZ) : warning: In the expression: MkT0 @ k_X1x2 @ a_a1wY @ k_X1x2 @ b_a1x0 dt_a1xC dt_X1xK Kinds don't match in type application: Type variable: a_X1xw :: k_X1x2 Arg type: a_a1wY :: k_a1wZ Linted Arg kind: k_a1wZ : warning: In the type ‘T0 a_a1wY’ Kind application error in type ‘T0 a_a1wY’ Function kind = forall k. k -> * Arg kinds = [(k_X1x2, *), (a_a1wY, k_a1wZ)] Fun: k_X1x2 (a_a1wY, k_a1wZ) : warning: In the expression: MkT0 @ k_X1x2 @ a_a1wY @ k_X1x2 @ b_a1x0 dt_a1xC dt_X1xK Kinds don't match in type application: Type variable: a_X1xw :: k_X1x2 Arg type: a_a1wY :: k_a1wZ Linted Arg kind: k_a1wZ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:01:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:01:43 -0000 Subject: [GHC] #16222: PPC NCG: C calling convention violated for integers smaller than word size Message-ID: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> #16222: PPC NCG: C calling convention violated for integers smaller than word size -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 (FFI) | Keywords: big endian | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime primops/should_run/PrimFFIInt8 | Blocked By: primops/should_run/PrimFFIInt16 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The C calling convention for powerpc64 and powerpc64le require simple integer types to be zero or sign extended to 64 bit. The PPC NCG assumes that all values have been promoted to word size but now we introduced integer operations on smaller than machine word size and in general we cannot assume that values have been promoted anymore. When a value is not promoted and passed to a foreign function on the stack that value will be in the wrong position within the stack slot on big endian systems and the function will deliver wrong results. On little endian systems we still get correct results as long as we stay in the smaller integer range. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:02:14 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:02:14 -0000 Subject: [GHC] #16222: PPC NCG: C calling convention violated for integers smaller than word size In-Reply-To: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> References: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> Message-ID: <062.f7cf9935d871beaff1e15efd94e9287f@haskell.org> #16222: PPC NCG: C calling convention violated for integers smaller than word size -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (FFI) | Version: 8.7 Resolution: | Keywords: big endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/PrimFFIInt8 | primops/should_run/PrimFFIInt16 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I am working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:04:04 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:04:04 -0000 Subject: [GHC] #16223: hWaitForInput is broken on Windows Message-ID: <046.56f0751f76756d0ce24bc91a94444df8@haskell.org> #16223: hWaitForInput is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noted in #16160: {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( hWaitForInput-accurate-socket.hs, hWaitForInput-accurate-socket.o ) hWaitForInput-accurate-socket.hs:8:1: error: Could not find module ‘System.Posix.IO’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. *** unexpected failure for hWaitForInput-accurate-socket(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:10:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:10:16 -0000 Subject: [GHC] #16223: hWaitForInput is broken on Windows In-Reply-To: <046.56f0751f76756d0ce24bc91a94444df8@haskell.org> References: <046.56f0751f76756d0ce24bc91a94444df8@haskell.org> Message-ID: <061.49fb64f02907200262811314958326d0@haskell.org> #16223: hWaitForInput is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Hopefully fixed in https://gitlab.haskell.org/ghc/ghc/merge_requests/201. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:31:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:31:50 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.83477d1a8cad1febf303158d78547e54@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Note: this is correcting a change brought in accidentally by bace26aadaafa4064e78f9ed088c1e2217221acc These kinds of regressions should be picked up in future by the more stringent test introduced in #16217 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:49:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:49:07 -0000 Subject: [GHC] #12920: Overzealous unused-top-binds In-Reply-To: <047.901081a81082358202634643f971c0b9@haskell.org> References: <047.901081a81082358202634643f971c0b9@haskell.org> Message-ID: <062.764558d3f284a47e970979927aab36af@haskell.org> #12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I just ran into this issue in a somewhat different context: {{{#!hs {-# OPTIONS_GHC -Wunused-top-binds #-} module Bug () where type A = Int type B = A type C = B a, b, c :: Int a = 42 b = a c = b }}} {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:6:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘C’ | 6 | type C = B | ^^^^^^^^^^ Bug2.hs:9:1: warning: [-Wunused-top-binds] Defined but not used: ‘a’ | 9 | a = 42 | ^ Bug2.hs:10:1: warning: [-Wunused-top-binds] Defined but not used: ‘b’ | 10 | b = a | ^ Bug2.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘c’ | 11 | c = b | ^ Ok, one module loaded. }}} It appears that `-Wunused-top-binds` has different transitivity behavior when it comes to functions vs. type synonyms: the former has transitive behavior, whereas the latter does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:54:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:54:58 -0000 Subject: [GHC] #12920: Overzealous unused-top-binds In-Reply-To: <047.901081a81082358202634643f971c0b9@haskell.org> References: <047.901081a81082358202634643f971c0b9@haskell.org> Message-ID: <062.b439749f1640e254bf065c06be6b9e9a@haskell.org> #12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): @RyanGlScott I think that is *exactly* the behavior I was seeing in the original ticket. Thanks for clarifying the problem (and somehow finding this ancient ticket!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 18:59:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 18:59:47 -0000 Subject: [GHC] #16224: CPUTime001 is fragile Message-ID: <046.14e27fa680beb0296780580789b4c71d@haskell.org> #16224: CPUTime001 is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have seen CPUTime001 fail spuriously on several occasions. In [[https://gitlab.haskell.org/ghc/ghc/-/jobs/15989|one such occasion]]: {{{#!diff --- libraries/base/tests/CPUTime001.run/CPUTime001.stdout.normalised 2019-01-23 18:53:32.601027719 +0000 +++ libraries/base/tests/CPUTime001.run/CPUTime001.run.stdout.normalised 2019-01-23 18:53:32.601027719 +0000 @@ -1,4 +1,4 @@ 1028457 1664079 2692537 -(True,True) +(False,True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 19:00:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 19:00:18 -0000 Subject: [GHC] #16224: CPUTime001 is fragile In-Reply-To: <046.14e27fa680beb0296780580789b4c71d@haskell.org> References: <046.14e27fa680beb0296780580789b4c71d@haskell.org> Message-ID: <061.9c13cc20aec4249fb4e3a76b7a008a36@haskell.org> #16224: CPUTime001 is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I have seen CPUTime001 fail spuriously on several occasions. In > [[https://gitlab.haskell.org/ghc/ghc/-/jobs/15989|one such occasion]]: > {{{#!diff > --- libraries/base/tests/CPUTime001.run/CPUTime001.stdout.normalised > 2019-01-23 18:53:32.601027719 +0000 > +++ libraries/base/tests/CPUTime001.run/CPUTime001.run.stdout.normalised > 2019-01-23 18:53:32.601027719 +0000 > @@ -1,4 +1,4 @@ > 1028457 > 1664079 > 2692537 > -(True,True) > +(False,True) > }}} New description: I have seen CPUTime001 fail spuriously on several occasions. In [[https://gitlab.haskell.org/ghc/ghc/-/jobs/15989|one such occasion]] on Debian 9 the `normal` testsuite way failed with: {{{#!diff --- libraries/base/tests/CPUTime001.run/CPUTime001.stdout.normalised 2019-01-23 18:53:32.601027719 +0000 +++ libraries/base/tests/CPUTime001.run/CPUTime001.run.stdout.normalised 2019-01-23 18:53:32.601027719 +0000 @@ -1,4 +1,4 @@ 1028457 1664079 2692537 -(True,True) +(False,True) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 19:17:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 19:17:18 -0000 Subject: [GHC] #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) Message-ID: <050.51ee2352f2a4dae51e64e4bda9769d8b@haskell.org> #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #16188, #16204 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles on GHC 8.0.2 through GHC 8.6.3 with `-dcore- lint`: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data family Sing :: k -> Type data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data TyCon1 :: (k1 -> k2) -> (k1 ~> k2) type instance Apply (TyCon1 f) x = f x data SomeApply :: (k ~> Type) -> Type where SomeApply :: Apply f a -> SomeApply f f :: SomeApply (TyCon1 Sing :: k ~> Type) -> SomeApply (TyCon1 Sing :: k ~> Type) f (SomeApply s) = SomeApply s }}} However, it chokes on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs -dcore-lint GHCi, version 8.7.20190120: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: SomeApply @ k_a1Dz @ (TyCon1 Sing) @ Any (s_a1Bq `cast` (Sub (D:R:ApplyabTyCon1x[0] _N <*>_N _N _N ; Sym (D:R:ApplyabTyCon1x[0] _N <*>_N _N _N)) :: Apply (TyCon1 Sing) a_a1DB ~R# Apply (TyCon1 Sing) Any)) Trans coercion mis-match: D:R:ApplyabTyCon1x[0] _N <*>_N _N _N ; Sym (D:R:ApplyabTyCon1x[0] _N <*>_N _N _N) Apply (TyCon1 Sing) a_a1DB Sing a_a1DB Sing Any Apply (TyCon1 Sing) Any *** Offending Program *** f :: forall k. SomeApply (TyCon1 Sing) -> SomeApply (TyCon1 Sing) [LclIdX] f = \ (@ k_a1Dz) (ds_d1EV :: SomeApply (TyCon1 Sing)) -> case ds_d1EV of wild_00 { SomeApply @ a_a1DB s_a1Bq -> break<0>(s_a1Bq) SomeApply @ k_a1Dz @ (TyCon1 Sing) @ Any (s_a1Bq `cast` (Sub (D:R:ApplyabTyCon1x[0] _N <*>_N _N _N ; Sym (D:R:ApplyabTyCon1x[0] _N <*>_N _N _N)) :: Apply (TyCon1 Sing) a_a1DB ~R# Apply (TyCon1 Sing) Any)) } }}} Note that if I change the definition of `Sing` to this: {{{#!hs data family Sing (a :: k) }}} Then the error goes away. Also, if I extend `SomeProxy` with an additional `proxy` field: {{{#!hs data SomeApply :: (k ~> Type) -> Type where SomeApply :: proxy a -> Apply f a -> SomeApply f f :: SomeApply (TyCon1 Sing :: k ~> Type) -> SomeApply (TyCon1 Sing :: k ~> Type) f (SomeApply p s) = SomeApply p s }}} Then the error also goes away. Perhaps `a` being ambiguous plays an important role here? Possibly related to #16188 or #16204. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 19:19:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 19:19:20 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.8eafdf975e81a12eefd6ec945f4d4bf7@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16204, #16225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #16204 => #16204, #16225 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 19:19:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 19:19:38 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) In-Reply-To: <050.809cff7906dca54b71168422e3269d5a@haskell.org> References: <050.809cff7906dca54b71168422e3269d5a@haskell.org> Message-ID: <065.85813631fd0926970b22532617b65e6d@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16188, #16225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #16188 => #16188, #16225 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 23 22:22:46 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Jan 2019 22:22:46 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.8e5756a75836e813e54182a3a84b487e@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I propose simply reversing the one line change in the Description. I do not know why that change was made. Why is it ugly to reverse it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 03:15:43 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 03:15:43 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.2cc83caf939538f7eca272336ce0e921@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Suppose we have {{{#!hs type family F a b where F _ _ = Bool }}} If we reverse the change, I believe we get that GHC reports that the equation is `F w1 w2 = Bool`. Perhaps that's better than what we have, but someone has to pay the price. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 04:20:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 04:20:57 -0000 Subject: [GHC] #16226: printf g format specifier doesn't match the C standard behaviour Message-ID: <047.5ee8e0935cd32030a56c81d44a594b1c@haskell.org> #16226: printf g format specifier doesn't match the C standard behaviour -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [nix-shell:/tmp]$ clang printg.c && ./a.out && cat printg.c 3122.55 #include int main(void) { printf("%.16g\n", 3122.55); } [nix-shell:/tmp]$ runhaskell printg.hs && cat printg.hs 3122.5500000000000000 import Text.Printf (printf) main = printf "%.16g\n" (3122.55 :: Double) }}} Some more info here https://stackoverflow.com/questions/54162152/what- precisely-does-the-g-printf-specifier-mean Notably I'd expect GHC to give me the same answer as the shown C program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 08:48:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 08:48:04 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.152f56d9b461f1e8c0e5efa188326a86@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by artempyanykh): No worries! Thanks Moritz, makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 09:33:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 09:33:25 -0000 Subject: [GHC] #16227: T15897 causes CI failures due to timing out Message-ID: <049.83b38b7e4fac1d345415f88c07f804e1@haskell.org> #16227: T15897 causes CI failures due to timing out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example: https://gitlab.haskell.org/ghc/ghc/-/jobs/16084 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 10:48:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 10:48:55 -0000 Subject: [GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP In-Reply-To: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> References: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> Message-ID: <062.a45169fadf12cefc4a3aa096064868ab@haskell.org> #16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.6.2 Resolution: | Keywords: Applicative, | Parsers, ReadP Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dbaynard): I can certainly give a reason to deprecate (I wouldn't underestimate the confusion caused by this inconsistency; error messages for functions of the same name are often difficult to process) but I'm not well placed to describe it as an advantage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 10:51:18 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 10:51:18 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.e1ef187e7c68c39b34bc5008e2b3be2e@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Gitlab merge request is open at https://gitlab.haskell.org/ghc/ghc/merge_requests/205 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 13:26:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 13:26:23 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.1ea6d4e268bfd65f3d2d8cb5a380caef@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Due to #16082, we're going to pretty-print certain things less than optimally regardless of whether we choose `w` or `_`—it's just a question of which pill we find easier to swallow. I don't have a strong opinion on the matter, but it is worth noting that the choice of `_` actually causes some things to be printed out in a manner that's flat-out incorrect. For example, here is the [https://gitlab.haskell.org/ghc/ghc/blob/master/testsuite/tests/partial- sigs/should_compile/Either.stderr stderr from the Either test]: {{{ TYPE SIGNATURES barry :: forall _. _ -> (Either [Char] _, Either [Char] _) Dependent modules: [] Dependent packages: [base-4.12.0.0, ghc-prim-0.5.3, integer-gmp-1.0.2.0] }}} Notice the use of `forall _` there, which isn't valid GHC code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 13:34:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 13:34:33 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.443268a4ec6a91e08b4a374f48023e52@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by onslaughtq): This issue has currently bit us as well, after we upgraded from using ghc 7.10.3 to ghc 8.6.3. We have an operator that we marked as INLINE and, when chaining the operator at least 12 times, as <*> is chained in the original bad.hs, compilation blows up. Marking the function with NOINLINE works, but using -O1 instead of -O2 doesn't. If necessary, I can provide code examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 14:40:47 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 14:40:47 -0000 Subject: [GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries Message-ID: <048.4844eff8eedd12903d2ac77488728672@haskell.org> #16228: ghc-pkg and ghc do not agree about package with internal libraries --------------------------------------+--------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Initially I reported this to Cabal (https://github.com/haskell/cabal/issues/5857), but I think this is actually a GHC bug. Repro here: https://github.com/michaelpj/cabal-bug-package-db In particular, you can run the following. {{{ $ cabal build $ ghc-pkg field test exposed -f dist/package.conf.inplace exposed: True $ ghc-pkg find-module Test -f dist/package.conf.inplace dist/package.conf.inplace test-0.1.0.0 $ ghc -package-db dist/package.conf.inplace Use.hs [1 of 1] Compiling Use ( Use.hs, Use.o ) Use.hs:3:1: error: Could not load module ‘Test’ It is a member of the hidden package ‘test-0.1.0.0’. You can run ‘:set -package test’ to expose it. (Note: this unloads all the modules in the current scope.) Use -v to see a list of the files searched for. | 3 | import Test | ^^^^^^^^^^^ $ ghc -package-db dist/package.conf.inplace -package test Use.hs [1 of 1] Compiling Use ( Use.hs, Use.o ) }}} That is: * `ghc-pkg` thinks the package is present, exposed, and contains the module in question. * `ghc` thinks the package is hidden, and will accept it when specified with `-package`. If you comment out the internal library this does not happen, but regardless it seems bad that there's a disagreement between `ghc-pkg` and `ghc`. I've also observed (although I don't have a small reproduction for this) a similar case where `ghc` does not even think the module is hidden, but again will accept it with `-package`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 15:00:22 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 15:00:22 -0000 Subject: [GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries In-Reply-To: <048.4844eff8eedd12903d2ac77488728672@haskell.org> References: <048.4844eff8eedd12903d2ac77488728672@haskell.org> Message-ID: <063.99d4049291bc6cec76ea1e904857d26b@haskell.org> #16228: ghc-pkg and ghc do not agree about package with internal libraries ---------------------------------+-------------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by michaelpj): Correction: the case where I do not get the "hidden package" message is using ghc 8.4.4, whereas in the other case I am using 8.6.3. I believe the latter has https://gitlab.haskell.org/ghc/ghc/commit/4c364402ad9edade698863a3684f395e737b9de2 but the former does not, so I think these are in fact exactly the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 17:37:48 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 17:37:48 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.271b35b4987172c61d1d5e371e5492da@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15437 Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Patch is now ready for preliminary review: https://gitlab.haskell.org/ghc/ghc/merge_requests/166 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 17:43:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 17:43:12 -0000 Subject: [GHC] #16229: Dump-parsed-ast fails for very large Fractional number constants Message-ID: <044.7d8d695580a9c43c8b93b0117ffc79e6@haskell.org> #16229: Dump-parsed-ast fails for very large Fractional number constants -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The existing test file `T15271.hs` has {{{#!hs main = do print 1e646457008 print 1e646457009 -- T15271: This incorrectly printed 0.0 print 1e1555550000 -- This is still infinity print 1e1000000000 -- T15271: This incorrectly printed 0.0 }}} Trying to run `ghc --dump-parsed-ast` T15271.hs` fails, using up all available memory. When dumping the file in ghc-exacptrint, the start looks like this {{{ ({ tests/examples/ghc88-copied/T15271.hs:2:9-19 } Just (Ann (DP (0,1)) [] [] [((G AnnVal),DP (0,0))] Nothing Nothing) (HsOverLit (NoExt) (OverLit (NoExt) (HsFractional (FL (SourceText "1e646457008") (False) (:% (100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ..... }}} I am not sure if this is an actual problem, but it is worth noting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 18:13:08 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 18:13:08 -0000 Subject: [GHC] #16229: Dump-parsed-ast fails for very large Fractional number constants In-Reply-To: <044.7d8d695580a9c43c8b93b0117ffc79e6@haskell.org> References: <044.7d8d695580a9c43c8b93b0117ffc79e6@haskell.org> Message-ID: <059.9eba73b11895935547f4b9ea88f3f118@haskell.org> #16229: Dump-parsed-ast fails for very large Fractional number constants -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is #15646 which is fixed in https://gitlab.haskell.org/ghc/ghc/merge_requests/55 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 18:20:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 18:20:11 -0000 Subject: [GHC] #16229: Dump-parsed-ast fails for very large Fractional number constants In-Reply-To: <044.7d8d695580a9c43c8b93b0117ffc79e6@haskell.org> References: <044.7d8d695580a9c43c8b93b0117ffc79e6@haskell.org> Message-ID: <059.a09343449e2ebfbc4a51d4e6701c0116@haskell.org> #16229: Dump-parsed-ast fails for very large Fractional number constants -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15646 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => duplicate * related: => #15646 Comment: Ok, closing as related, and patch landing soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 18:48:35 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 18:48:35 -0000 Subject: [GHC] #16203: Unhelpful names for wildcard type variables In-Reply-To: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> References: <046.6b19b845d9a44c6fda5ca721f540a890@haskell.org> Message-ID: <061.5a90ea5dd92377b758e78e49728587ed@haskell.org> #16203: Unhelpful names for wildcard type variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps in light of comment:6, we should revert that one-line change. But the bug just morphs into a different suboptimal pretty-printing... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 18:57:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 18:57:21 -0000 Subject: [GHC] #16230: API Annotations: more explicit foralls fixup Message-ID: <044.42a15601640ae89d68991169845c06ab@haskell.org> #16230: API Annotations: more explicit foralls fixup -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `AnnForall` annotations introduced via Phab:D4894 are not always attached to the correct `SourceSpan`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 18:57:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 18:57:33 -0000 Subject: [GHC] #16230: API Annotations: more explicit foralls fixup In-Reply-To: <044.42a15601640ae89d68991169845c06ab@haskell.org> References: <044.42a15601640ae89d68991169845c06ab@haskell.org> Message-ID: <059.448ad88dbf1f1fc9eef207e8e04b2e11@haskell.org> #16230: API Annotations: more explicit foralls fixup -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 19:58:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 19:58:27 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.86d83bd55f70531586404fb9cefb1356@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hussein.aitlahcen): Hello everyone, My team experience the same issue when using Squeal extensively (https://github.com/morphismtech/squeal). I found two things: - GHC is unfolding the exported types (a lot of type families involved) in the `.hi` file. - Stack is asking GHC to dump the `.hi` to know which module it has to rebuild (https://github.com/commercialhaskell/stack/blob/master/src/Stack/Build/Execute.hs#L1977). This exact thing is making GHC crazy, forcing him to dump a pretty printed 3.5gb .txt (head of the file https://gist.githubusercontent.com/haitlahcen/3f1e83cdc78d48ed2100d51a0ea05844/raw/c49218be742cd3d2450a8f13683a04339b1ab9e7/hi.txt). Because of that, GHC was taking **12gb+** to compile some files. I found that omitting the interfaces pragmas with `-fomit-interface-pragmas` was helping a lot. In fact, no more unfolded type in the interface file, making the dumped .txt file going from **3.5gb** to **700kb** with a maximum allocated memory of **2.5gb**. I already patched Stack to stop asking for a dump and directly read the binary interface file (the startup time is greatly improved) and will probably push a PR. Finally, It looks like unfolding options for GHC does not apply to types (or I missed something?). I'm asking because of https://github.com/ghc/ghc/blob/886ddb27bfbbb52c41690cd29e2ab3ed80bf5450/compiler/coreSyn/CoreUnfold.hs#L583. Since we are now able to compute stuff at type level, it would be handy to be able to control the unfolding depending on the `typeLevelExprSize`. Thanks for reading -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 20:50:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 20:50:11 -0000 Subject: [GHC] #16224: CPUTime001 is fragile In-Reply-To: <046.14e27fa680beb0296780580789b4c71d@haskell.org> References: <046.14e27fa680beb0296780580789b4c71d@haskell.org> Message-ID: <061.52e40b4af5bc3eea4e58effffe783d6c@haskell.org> #16224: CPUTime001 is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm actually getting rather concerned that this might be a new regression. I've seen this fail suspiciously often in the last few days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 21:03:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 21:03:15 -0000 Subject: [GHC] #16220: -Wmissing-signatures should warn when top-level signature is partial In-Reply-To: <047.70a8a8f1d630aaa098c9ebe6acff83dd@haskell.org> References: <047.70a8a8f1d630aaa098c9ebe6acff83dd@haskell.org> Message-ID: <062.c0eaf09e6119ace522d1d0f7c13a7c8f@haskell.org> #16220: -Wmissing-signatures should warn when top-level signature is partial -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This would be subsumed by [https://github.com/ghc-proposals/ghc- proposals/pull/194 my proposal] on the matter, right? (Yes, I saw that you linked there.) Just checking that the proposal would satisfy your use- case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 22:19:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 22:19:39 -0000 Subject: [GHC] #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. Message-ID: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reason seems to be that it's placed in bin, but windows looks for it under lib. Or at least it works if I copy the file over manually. GHCi works fine under msys however so only the windows shells seem to be affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 22:23:53 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 22:23:53 -0000 Subject: [GHC] #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. In-Reply-To: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> References: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> Message-ID: <062.30460c4aa8cbaa49991e705ff8823e06@haskell.org> #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): To be more precise the file is under `.\_build\mingw\bin\libgmp-10.dll` but GHC seems to look for it under `.\_build\mingw\lib\`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 22:34:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 22:34:34 -0000 Subject: [GHC] #16232: Add setField to HasField Message-ID: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: ORF | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the implementation of https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0042-record-set-field.rst I've made a start on the implementation but have a question on which I'd appreciate some input: how should the dictionary for `HasField` be generated? To recap, recall that at present, `HasField x r a` is coercible to `r -> a` so the dictionary can be constructed merely by taking the selector function for the field and wrapping it in an appropriate coercion. With the proposal, `HasField x r a` will instead be represented as `r -> (a -> r, a)` where the first component of the tuple is an update function. The problem is how to define this update function in Core. This function should perform case analysis on the record data type, where each case replaces the value of the field being updated and preserves all the other fields. For example, given a data type `data T = MkT { foo :: Int, bar :: Bool }` we need to generate {{{#!hs \ r x -> case r of MkT {foo = _, bar = bar} -> MkT { foo = x, bar = bar } }}} The most obvious approach is to generate well-typed Core for the update function directly, but this seems to be rather complex, in particular because of the worker/wrapper distinction, as one ends up reconstructing much of the typechecking/desugaring for record pattern matching and construction. This also seems like a lot of work to do every time a `HasField` constraint is solved. Would it be reasonable to generate update functions for fields at definition sites, as we do for selector functions? I've implemented this in the past, and it is relatively simple to generate renamed syntax to feed in to the type-checker. However, this would add some overhead for every field, even if `HasField` was not subsequently used, and would require some naming scheme for update functions. Or are there other options? Is there some way to solve a `HasField` constraint and construct its dictionary by emitting renamed syntax for subsequent type-checking, such that subsequently solving similar constraints will use the same dictionary? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 22:52:24 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 22:52:24 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.de715d5ac0a42218a8137690d9f995d0@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It seems quite straightforward to generate the necessary core. I think you mean that you would generate: {{{ \ r x -> case r of MkT _ bar -> MkT x bar }}} You don't need to mention any wired-in Ids or anything so it seems simple? It also doesn't seem like a lot of work to me in the grand scheme of things so I wouldn't mind doing it every time one of these constraints is solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 24 22:56:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Jan 2019 22:56:41 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.aa1a43e273a7a1ff2313356317938d81@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I suggest taking the direct path, and generate an update function for each field. Its more work than Matthew says because we may need to evaluate the argument (for strict constructors) or unbox it (if the argument is UNPACKed). This would ''replace'' the selector function would it not? The new function is a selector and update function? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 01:32:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 01:32:35 -0000 Subject: [GHC] #16233: HIE file generation is inefficient Message-ID: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> #16233: HIE file generation is inefficient -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Generating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this: * Every expression in the AST is desugared via `deSugarExpr` for the purpose of extracting a type. GHC ends up doing the same work multiple times for the same nodes. Ex: in order to desugar `HsApp _ fun arg`, GHC desugars both `fun` and `arg`, yet the HIE code doesn't cache that (so it ends up desugaring `fun` and `arg` at least once more). * There is a lot of stuff being written into these HIE files, making them quite big (even after compressing/deduplicating type information). One data point: the largest HIE file at time of writing is `Parser.hie`, which is 7.2MB, compared to just 58K for `Parser.hi`Q Writing large files is naturally going to take up memory and be slow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 02:47:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 02:47:28 -0000 Subject: [GHC] #16234: Unable to resolve type families Message-ID: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> #16234: Unable to resolve type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #16211 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} import Control.Monad.Classes (MonadReader) --import Control.Monad.Primitive () import Control.Monad.Trans.State.Lazy (StateT) main :: (n ~ StateT () IO, MonadReader () n) => IO () main = undefined }}} produces the error (cleaned up for readability) {{{ Main.hs:9:1: error: * No instance for (monad-classes.MonadReaderN (monad-classes.FindTrue '[monad-classes.CanDo (StateT () IO) (monad-classes.EffReader ()), monad-classes.CanDo IO (monad-classes.EffReader ())]) () (StateT () IO)) arising from a use of `main' * In the expression: main When checking the type of the IO action `main' | 9 | main = undefined | ^ }}} This is the same error as #16211, but that ticket uses a slightly different example to trigger the error upon recompile. The relevant instances are all available in `monad-classes`. {{{ class Monad m => MonadReaderN (n :: Peano) r m instance Monad m => MonadReaderN Zero r (StateT r m) type family CanDo (m :: (* -> *)) (eff :: k) :: Bool type instance CanDo (StateT s m) eff = StateCanDo s eff type family StateCanDo s eff where StateCanDo s (EffState s) = True StateCanDo s (EffReader s) = True type family FindTrue (bs :: [Bool]) :: Peano where FindTrue (True ': t) = Zero FindTrue (False ': t) = Succ (FindTrue t) data EffReader (e :: *) }}} I can reproduce with the attached package using GHC-8.6.3 and cabal: {{{ $ cabal sandbox init $ cabal install --only-dependencies $ cabal build }}} I was unable to minimize the attached example any further. Here's two ways to make the error go away: 1. `import Control.Monad.Primitive ()`. It's unclear why this would help because according to the maintainer of monad-classes, it has no transitive dependencies on `primitive`. 2. Change the signature of `main` to `main :: (MonadReader () (StateT () IO) => IO ()` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 02:47:50 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 02:47:50 -0000 Subject: [GHC] #16234: Unable to resolve type families In-Reply-To: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> References: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> Message-ID: <062.36c31f010437ef21455d273f4307caa8@haskell.org> #16234: Unable to resolve type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16211 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "bug.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 03:06:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 03:06:32 -0000 Subject: [GHC] #16234: Unable to resolve type families In-Reply-To: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> References: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> Message-ID: <062.d302df6c4a5007318e051df9187e950d@haskell.org> #16234: Unable to resolve type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16211 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I can reproduce this. Interestingly, if you glom all the relevant definitions into one file, the bug goes away. I have not done further exploration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 06:11:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 06:11:10 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.7a88628716aedd2aa664e07d9863f35d@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8040 | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): After running a hadrian build I see a clean working copy. Perhaps this ticket can be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 08:46:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 08:46:05 -0000 Subject: [GHC] #16234: Unable to resolve type families In-Reply-To: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> References: <047.a2cdc9e108aa86dcf9a8dda773f686cd@haskell.org> Message-ID: <062.d90beab44dea8f07391508051cc0f6f5@haskell.org> #16234: Unable to resolve type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16211 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Given that: 1. This seems to require installing things in a package database to trigger, 2. It relies crucially on type families, and 3. The type families unpredictably reduce I wonder if this is related to #11084 in some way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 09:54:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 09:54:43 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.054c7c8bc07cc5a94ef72a37148e068f@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T13839 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/215 -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Phab:D5449 => https://gitlab.haskell.org/ghc/ghc/merge_requests/215 Comment: @osa1 Finally I moved the patch from Phabricator to Gitlab. Sorry for the delay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 13:06:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 13:06:01 -0000 Subject: [GHC] #16235: Hadrian devel2 builds Haddock Message-ID: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> #16235: Hadrian devel2 builds Haddock -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ... but `make` did not, with devel2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 13:13:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 13:13:05 -0000 Subject: [GHC] #16235: Hadrian devel2 builds Haddock In-Reply-To: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> References: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> Message-ID: <062.deb3c3f542d3c2fc21334365bba42573@haskell.org> #16235: Hadrian devel2 builds Haddock -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 13:25:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 13:25:41 -0000 Subject: [GHC] #16236: API Annotations: AnnAt disconnected for TYPEAPP Message-ID: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> #16236: API Annotations: AnnAt disconnected for TYPEAPP -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the code {{{#!hs type family F1 (a :: k) (f :: k -> Type) :: Type where F1 @Peano a f = T @Peano f a }}} the API annotation for the first `@` is not attached to a `SourcSpan` in the `ParsedSource` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 13:25:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 13:25:57 -0000 Subject: [GHC] #16236: API Annotations: AnnAt disconnected for TYPEAPP In-Reply-To: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> References: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> Message-ID: <059.d3e704703fd2fa90bd216af74c0ec5e1@haskell.org> #16236: API Annotations: AnnAt disconnected for TYPEAPP -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 13:59:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 13:59:24 -0000 Subject: [GHC] #16237: Run check-api-annotations and check-ppr on all parseable test code Message-ID: <044.2503d3cf95ee184bde32f2c57413aaec@haskell.org> #16237: Run check-api-annotations and check-ppr on all parseable test code -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `check-ppr` utility checks that `parse (ppr (parse s)) === parse s` holds, when given a file to test. Likewise, the `check-api-annotations` utility checks that all API annotations are actually attached to the `ParsedSource` output, and that they do not precede their attachment span. At the moment these checks are only run on a subset of code, as explicitly called for in the `/testsuite/tests/printer` and `/testsuite/tests/ghc- api/annotations` tests. These properties are supposed to hold for all GHC parseable haskell. So rather than requiring individual developers to add specific tests to confirm their new features work properly, extend the test framework to make a pass over all the files that are expected to be parseable, and run these checks on them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 14:26:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 14:26:41 -0000 Subject: [GHC] #16213: Unnecessary error In-Reply-To: <049.d570e9e2d8db590facfbba25ee4ee5f9@haskell.org> References: <049.d570e9e2d8db590facfbba25ee4ee5f9@haskell.org> Message-ID: <064.aa4ae3bd0c9dffdc482c37f4a477e8c8@haskell.org> #16213: Unnecessary error -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 14:28:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 14:28:49 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.daf4656bb58848a2ea3b5e2b604d2181@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: (none) => adamgundry Comment: > I suggest taking the direct path, and generate an update function for each field. Sorry, to be clear, do you mean the approach of generating renamed syntax at definition sites? > Its more work than Matthew says because we may need to evaluate the argument (for strict constructors) or unbox it (if the argument is UNPACKed). Exactly, perhaps my example didn't do a good job of conveying the awkward points here. Let me see if I understand correctly what generating Core directly needs to do in the general case: * When we pattern match in Core, we match on the *worker* (binding its existential tyvars, theta and the arguments as given by `dataConInstSig`). * We can use `dataConBoxer` to build let-bindings for the arguments to the wrapper out of the bound variables from matching on the worker. * We need to construct an application of the *wrapper* to appropriate boxed arguments, replacing the one that corresponds to the field being updated with the new value. I don't understand very clearly how to do this. In particular, I'm not sure how to figure out the order in which to instantiate type variables and dictionaries in the wrapper's type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 14:32:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 14:32:05 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.498615b8729eccc06b49b7c5a449a054@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You are right that does seem a bit tricky. Another possibility is generating renamed syntax when solving the constraint then type checking it and desugaring it using `tcExpr` and `dsExpr` to generate the necessary evidence? This is all possible to do in `ClsInst`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 14:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 14:51:02 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.14f22fa63e929786e72114cd34b5609a@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I think the [https://github.com/sgraf812/late-lam- lift/blob/master/paper.pdf paper] is now in a good shape for feedback. simonpj, would you give it a try? I marked some places with a TODO where I'd particularly appreciate another opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 15:42:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 15:42:23 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.d32bdab3f8a26c0122c779700147d6ed@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Sorry, to be clear, do you mean the approach of generating renamed syntax at definition sites? Yes -- essentially replacing the stuff where we generate record selectors by stuff that generates this compound selector/updater function; plus perhaps generating the legacy selector function from that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 15:51:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 15:51:04 -0000 Subject: [GHC] #16235: Hadrian devel2 builds Haddock In-Reply-To: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> References: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> Message-ID: <062.b64ab8c4de5c3275c51ea14f909a484a@haskell.org> #16235: Hadrian devel2 builds Haddock -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): What is the argument to not build it? If your change breaks haddock then you should know about it and fix it so it's useful that it builds. If don't want to build it, you can run {{{ /hadrian/build.sh --freeze1 stage2:exe:ghc-bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 15:54:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 15:54:03 -0000 Subject: [GHC] #16103: docs-haddock Hadrian target doesn't work reliably In-Reply-To: <050.924a903dce685538d1f289c25038f6ec@haskell.org> References: <050.924a903dce685538d1f289c25038f6ec@haskell.org> Message-ID: <065.1e7a0cf46b02286d2580af76c6210bef@haskell.org> #16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It could be working by accident if it's now fixed rather than by design but I suppose we should close this ticket until it resurfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 15:54:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 15:54:08 -0000 Subject: [GHC] #16103: docs-haddock Hadrian target doesn't work reliably In-Reply-To: <050.924a903dce685538d1f289c25038f6ec@haskell.org> References: <050.924a903dce685538d1f289c25038f6ec@haskell.org> Message-ID: <065.86e6c1e708efe87c5deebee532004e7f@haskell.org> #16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 15:54:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 15:54:42 -0000 Subject: [GHC] #16214: Hadrian prof flavour doesn't build a compiler which you can profile In-Reply-To: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> References: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> Message-ID: <064.fb630c6a47fe0aa9d1703bc3b47f2fb2@haskell.org> #16214: Hadrian prof flavour doesn't build a compiler which you can profile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Merged: cfe64019a70acc1bae76f2fa580d6654f8eb5bc4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 16:05:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 16:05:33 -0000 Subject: [GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries In-Reply-To: <048.4844eff8eedd12903d2ac77488728672@haskell.org> References: <048.4844eff8eedd12903d2ac77488728672@haskell.org> Message-ID: <063.79ee54959cb50d05f0387c2aa9145cc0@haskell.org> #16228: ghc-pkg and ghc do not agree about package with internal libraries ---------------------------------+-------------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by michaelpj): With 8.6.3 I can now sometimes only fix the problem by passing the full package id, the package name no longer succeeds in unhiding it. Sadly that makes my workaround quite a bit trickier... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 16:07:40 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 16:07:40 -0000 Subject: [GHC] #16235: Hadrian devel2 builds Haddock In-Reply-To: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> References: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> Message-ID: <062.e6e9a9caae7668a5fa2cf53d7e472c0f@haskell.org> #16235: Hadrian devel2 builds Haddock -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm of two minds on this. On one hand, if you're using the `devel2` flavour, you most likely only care about debugging GHC itself, and you probably don't care about frivolities like Haddock. On the other hand, Haddock //is// a pretty integral part of the GHC bindist, and it could be argued that not building it in `devel2` is tantamount to not testing an important code path. (FWIW, I first noticed this quirk when using the `quick` flavour, which is another place where the `make`-based build system also did not build Haddock. I suppose I rationalized this as trying to finish the build, y'know, //quick//ly as possible, but this reasoning might not actually hold water in light of the reasoning above.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 16:23:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 16:23:23 -0000 Subject: [GHC] #16210: Hadrian devel2 flavour builds profiling way In-Reply-To: <049.3cb854d79d59d174586568a12c4e09ce@haskell.org> References: <049.3cb854d79d59d174586568a12c4e09ce@haskell.org> Message-ID: <064.889c95728c5f69db83f17d7ae0e726f1@haskell.org> #16210: Hadrian devel2 flavour builds profiling way -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Fixed in: https://gitlab.haskell.org/ghc/ghc/merge_requests/216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 16:28:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 16:28:44 -0000 Subject: [GHC] #16235: Hadrian devel2 builds Haddock In-Reply-To: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> References: <047.4ad8f7ef8d7f175688b94aae08a0637e@haskell.org> Message-ID: <062.7c1ef60ee65ee35372f6beb8d4c2ac02@haskell.org> #16235: Hadrian devel2 builds Haddock -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree that we should testing building and operation of haddock -- that's what validation is for. But, if I'm twiddling the setup of the `HsSyn` AST, I don't want to have to update Haddock as I go, until the new AST is all settled. You're right that I can just build one part of GHC (the compiler), but I still think it's better to default away from Haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 16:40:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 16:40:42 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.47c63fcd2dd3cfe0e41d2055ffea3b2f@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8040 | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * status: new => closed * resolution: => fixed Comment: I'm pretty sure this ticket has been resolved a long time ago, so I'm closing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 17:01:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 17:01:32 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.079540fa6fe720f6f0f711506d987bf6@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by josef): @goldfile can you elaborate on what you mean by incorrect impredicativity? I don't have a concrete plan yet, but it seems to me that, at least in the case of ApplicativeDo, this is mostly a matter of making sure that the algorithm which groups statements doesn't place the LetStmts in unfortunate positions. In the example by @vdukhovni the renamer produces the following very unfortunate code: {{{ Poly.main :: IO () Poly.main = do join (line_a1Wh <- getLine | locker_a1Wj <- do lock_a1Wi <- newMVar () let locker_a1Wj :: Poly.Locker locker_a1Wj = withMVar lock_a1Wi . const return locker_a1Wj) Poly.f line_a1Wh locker_a1Wj }}} It would have been much better if the let statement had been pulled out from inside the join and just on top of the last line. Indeed, if we change the example slightly we can actually make GHC accept the program: {{{ main :: IO () main = do line <- getLine lock <- newMVar () let locker :: Locker locker = withMVar lock . const res <- f line locker return res }}} The above program produces the following after renaming: {{{ main_a1Yv = do join (line_a1XS <- getLine | lock_a1XT <- newMVar ()) let locker_a1XU :: Locker locker_a1Z3 = withMVar lock_a1XT . const res_a1XV <- f line_a1XS locker_a1XU return res_a1XV }}} Just what we want! @vdukhovni, transforming let into where doesn't work in the general case unfortunately. Suppose that you had used either of the variables `line` or `lock` in your let statement. There would have been no way of transforming that into a where clause since those variables are not in scope in the where clause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 17:14:18 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 17:14:18 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.63c1a73962e25777087c7f00cc1a88b4@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. I confess I don't understand your syntax (what do the `<-` and `|` mean? the former usually requires `do`, but there isn't one; and I'm utterly lost on the `|`), but if your solution is just to rejigger the desugaring, then I'm sure that's pretty harmless. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 17:31:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 17:31:45 -0000 Subject: [GHC] #16238: Hadrian provides no way to accept output of test Message-ID: <049.1873139ea1b4f6b0248689aa8bba7e65@haskell.org> #16238: Hadrian provides no way to accept output of test -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can't find a way to make Hadrian generate the output for a test. In the old build system this used to be `make accept`. Marking this as high priority as this makes it hard to use for adding test cases which fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 18:40:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 18:40:30 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock Message-ID: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ #!sh # running: build -V _validate-bug/docs/html/libraries/base/base.haddock | Run Haddock BuildPackage: libraries/base/Control/Applicative.hs (and 236 more) => _validate-bug/docs/html/libraries/base/base.haddock _validate-bug/stage1/bin/haddock --verbosity=0 -B_validate-bug/stage1/lib --lib=_validate-bug/stage1/lib --odir=_validate- bug/docs/html/libraries/base --no-tmp-comp-dir --dump-interface=_validate- bug/docs/html/libraries/base/base.haddock --html --hyperlinked-source --hoogle --quickjump '--title=base-4.12.0.0: Basic libraries' --prologue =_validate-bug/docs/html/libraries/base/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2220 --hide=Control.Monad.ST.Imp --hide=Control.Monad.ST.Lazy.Imp --hide=Data.Functor.Utils --hide=Data.OldList --hide=Data.Semigroup.Internal --hide=Data.Typeable.Internal --hide=Foreign.ForeignPtr.Imp --hide=GHC.StaticPtr.Internal --hide=System.Environment.ExecutablePath --hide=System.CPUTime.Utils --hide=GHC.Event.Arr --hide=GHC.Event.Array --hide=GHC.Event.Control --hide=GHC.Event.EPoll --hide=GHC.Event.IntTable --hide=GHC.Event.Internal --hide=GHC.Event.KQueue --hide=GHC.Event.Manager --hide=GHC.Event.PSQ --hide=GHC.Event.Poll --hide=GHC.Event.Thread --hide=GHC.Event.TimerManager --hide=GHC.Event.Unique --hide=System.CPUTime.Posix.ClockGetTime --hide=System.CPUTime.Posix.Times --hide=System.CPUTime.Posix.RUsage --hide=System.CPUTime.Unsupported --read-interface=../ghc-prim,../ghc-prim/src/%{MODULE}.html#%{NAME },_validate-bug/docs/html/libraries/ghc-prim/ghc-prim.haddock --read- interface=../integer-gmp,../integer-gmp/src/%{MODULE}.html#%{NAME },_validate-bug/docs/html/libraries/integer-gmp/integer-gmp.haddock --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc =-hide-all-packages --optghc=-no-user-package-db '--optghc=-this-unit-id base-4.12.0.0' '--optghc=-package-id ghc-prim-0.5.3' '--optghc=-package-id integer-gmp-1.0.2.0' '--optghc=-package-id rts-1.0' --optghc=-i --optghc =-i_validate-bug/stage1/libraries/base/build --optghc=-i_validate- bug/stage1/libraries/base/build/autogen --optghc=-ilibraries/base/. --optghc=-Iincludes --optghc=-I_validate-bug/generated --optghc =-I_validate-bug/stage1/libraries/base/build --optghc=-I/nix/store /jxaaf8dsrb16vnwnij69jar7mhhj969q-ghc-build-environment/include --optghc =-I_validate-bug/stage1/libraries/base/build/include --optghc=-Ilibraries/base/include --optghc=-I/nix/store /jxaaf8dsrb16vnwnij69jar7mhhj969q-ghc-build-environment/include --optghc=-I/home/alp/WT/ghc-gitlab/_validate-bug/stage1/lib/x86_64-linux- ghc-8.7.20190123/integer-gmp-1.0.2.0/include --optghc=-I/home/alp/WT/ghc- gitlab/_validate-bug/stage1/lib/x86_64-linux- ghc-8.7.20190123/rts-1.0/include --optghc=-I_validate-bug/generated --optghc=-optc-I_validate-bug/generated --optghc=-optP-include --optghc =-optP_validate-bug/stage1/libraries/base/build/autogen/cabal_macros.h --optghc=-outputdir --optghc=_validate-bug/stage1/libraries/base/build --optghc=-this-unit-id --optghc=base --optghc=-Wcompat --optghc =-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc =-ghcversion-file=/home/alp/WT/ghc-gitlab/_validate- bug/generated/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno- trustworthy-safe libraries/base/Control/Applicative.hs libraries/base/Control/Arrow.hs libraries/base/Control/Category.hs libraries/base/Control/Concurrent.hs libraries/base/Control/Concurrent/Chan.hs libraries/base/Control/Concurrent/MVar.hs libraries/base/Control/Concurrent/QSem.hs libraries/base/Control/Concurrent/QSemN.hs libraries/base/Control/Exception.hs libraries/base/Control/Exception/Base.hs libraries/base/Control/Monad.hs libraries/base/Control/Monad/Fail.hs libraries/base/Control/Monad/Fix.hs libraries/base/Control/Monad/IO/Class.hs libraries/base/Control/Monad/Instances.hs libraries/base/Control/Monad/ST.hs libraries/base/Control/Monad/ST/Imp.hs libraries/base/Control/Monad/ST/Lazy.hs libraries/base/Control/Monad/ST/Lazy/Imp.hs libraries/base/Control/Monad/ST/Lazy/Safe.hs libraries/base/Control/Monad/ST/Lazy/Unsafe.hs libraries/base/Control/Monad/ST/Safe.hs libraries/base/Control/Monad/ST/Strict.hs libraries/base/Control/Monad/ST/Unsafe.hs libraries/base/Control/Monad/Zip.hs libraries/base/Data/Bifoldable.hs libraries/base/Data/Bifunctor.hs libraries/base/Data/Bitraversable.hs libraries/base/Data/Bits.hs libraries/base/Data/Bool.hs libraries/base/Data/Char.hs libraries/base/Data/Coerce.hs libraries/base/Data/Complex.hs libraries/base/Data/Data.hs libraries/base/Data/Dynamic.hs libraries/base/Data/Either.hs libraries/base/Data/Eq.hs libraries/base/Data/Fixed.hs libraries/base/Data/Foldable.hs libraries/base/Data/Function.hs libraries/base/Data/Functor.hs libraries/base/Data/Functor/Classes.hs libraries/base/Data/Functor/Compose.hs libraries/base/Data/Functor/Const.hs libraries/base/Data/Functor/Contravariant.hs libraries/base/Data/Functor/Identity.hs libraries/base/Data/Functor/Product.hs libraries/base/Data/Functor/Sum.hs libraries/base/Data/Functor/Utils.hs libraries/base/Data/IORef.hs libraries/base/Data/Int.hs libraries/base/Data/Ix.hs libraries/base/Data/Kind.hs libraries/base/Data/List.hs libraries/base/Data/List/NonEmpty.hs libraries/base/Data/Maybe.hs libraries/base/Data/Monoid.hs libraries/base/Data/OldList.hs libraries/base/Data/Ord.hs libraries/base/Data/Proxy.hs libraries/base/Data/Ratio.hs libraries/base/Data/STRef.hs libraries/base/Data/STRef/Lazy.hs libraries/base/Data/STRef/Strict.hs libraries/base/Data/Semigroup.hs libraries/base/Data/Semigroup/Internal.hs libraries/base/Data/String.hs libraries/base/Data/Traversable.hs libraries/base/Data/Tuple.hs libraries/base/Data/Type/Bool.hs libraries/base/Data/Type/Coercion.hs libraries/base/Data/Type/Equality.hs libraries/base/Data/Typeable.hs libraries/base/Data/Typeable/Internal.hs libraries/base/Data/Unique.hs libraries/base/Data/Version.hs libraries/base/Data/Void.hs libraries/base/Data/Word.hs libraries/base/Debug/Trace.hs libraries/base/Foreign.hs libraries/base/Foreign/C.hs libraries/base/Foreign/C/Error.hs libraries/base/Foreign/C/String.hs libraries/base/Foreign/C/Types.hs libraries/base/Foreign/Concurrent.hs libraries/base/Foreign/ForeignPtr.hs libraries/base/Foreign/ForeignPtr/Imp.hs libraries/base/Foreign/ForeignPtr/Safe.hs libraries/base/Foreign/ForeignPtr/Unsafe.hs libraries/base/Foreign/Marshal.hs libraries/base/Foreign/Marshal/Alloc.hs libraries/base/Foreign/Marshal/Array.hs libraries/base/Foreign/Marshal/Error.hs libraries/base/Foreign/Marshal/Pool.hs libraries/base/Foreign/Marshal/Safe.hs libraries/base/Foreign/Marshal/Unsafe.hs libraries/base/Foreign/Marshal/Utils.hs libraries/base/Foreign/Ptr.hs libraries/base/Foreign/Safe.hs libraries/base/Foreign/StablePtr.hs libraries/base/Foreign/Storable.hs libraries/base/GHC/Arr.hs libraries/base/GHC/Base.hs libraries/base/GHC/ByteOrder.hs libraries/base/GHC/Char.hs _validate- bug/stage1/libraries/base/build/GHC/Clock.hs libraries/base/GHC/Conc.hs libraries/base/GHC/Conc/IO.hs libraries/base/GHC/Conc/Signal.hs libraries/base/GHC/Conc/Sync.hs libraries/base/GHC/ConsoleHandler.hs libraries/base/GHC/Constants.hs libraries/base/GHC/Desugar.hs libraries/base/GHC/Enum.hs libraries/base/GHC/Environment.hs libraries/base/GHC/Err.hs libraries/base/GHC/Event.hs libraries/base/GHC/Event/Arr.hs libraries/base/GHC/Event/Array.hs libraries/base/GHC/Event/Control.hs _validate- bug/stage1/libraries/base/build/GHC/Event/EPoll.hs libraries/base/GHC/Event/IntTable.hs libraries/base/GHC/Event/Internal.hs _validate-bug/stage1/libraries/base/build/GHC/Event/KQueue.hs libraries/base/GHC/Event/Manager.hs libraries/base/GHC/Event/PSQ.hs _validate-bug/stage1/libraries/base/build/GHC/Event/Poll.hs libraries/base/GHC/Event/Thread.hs libraries/base/GHC/Event/TimerManager.hs libraries/base/GHC/Event/Unique.hs libraries/base/GHC/Exception.hs libraries/base/GHC/Exception/Type.hs libraries/base/GHC/ExecutionStack.hs _validate-bug/stage1/libraries/base/build/GHC/ExecutionStack/Internal.hs libraries/base/GHC/Exts.hs libraries/base/GHC/Fingerprint.hs libraries/base/GHC/Fingerprint/Type.hs libraries/base/GHC/Float.hs libraries/base/GHC/Float/ConversionUtils.hs libraries/base/GHC/Float/RealFracMethods.hs libraries/base/GHC/Foreign.hs libraries/base/GHC/ForeignPtr.hs libraries/base/GHC/GHCi.hs libraries/base/GHC/Generics.hs libraries/base/GHC/IO.hs libraries/base/GHC/IO/Buffer.hs libraries/base/GHC/IO/BufferedIO.hs libraries/base/GHC/IO/Device.hs libraries/base/GHC/IO/Encoding.hs libraries/base/GHC/IO/Encoding/CodePage.hs libraries/base/GHC/IO/Encoding/Failure.hs libraries/base/GHC/IO/Encoding/Iconv.hs libraries/base/GHC/IO/Encoding/Latin1.hs libraries/base/GHC/IO/Encoding/Types.hs libraries/base/GHC/IO/Encoding/UTF16.hs libraries/base/GHC/IO/Encoding/UTF32.hs libraries/base/GHC/IO/Encoding/UTF8.hs libraries/base/GHC/IO/Exception.hs libraries/base/GHC/IO/FD.hs libraries/base/GHC/IO/Handle.hs libraries/base/GHC/IO/Handle/FD.hs libraries/base/GHC/IO/Handle/Internals.hs _validate- bug/stage1/libraries/base/build/GHC/IO/Handle/Lock.hs libraries/base/GHC/IO/Handle/Text.hs libraries/base/GHC/IO/Handle/Types.hs libraries/base/GHC/IO/IOMode.hs libraries/base/GHC/IO/Unsafe.hs libraries/base/GHC/IOArray.hs libraries/base/GHC/IORef.hs libraries/base/GHC/Int.hs libraries/base/GHC/List.hs libraries/base/GHC/MVar.hs libraries/base/GHC/Maybe.hs libraries/base/GHC/Natural.hs libraries/base/GHC/Num.hs libraries/base/GHC/OldList.hs libraries/base/GHC/OverloadedLabels.hs libraries/base/GHC/Pack.hs libraries/base/GHC/Profiling.hs libraries/base/GHC/Ptr.hs _validate- bug/stage1/libraries/base/build/GHC/RTS/Flags.hs libraries/base/GHC/Read.hs libraries/base/GHC/Real.hs libraries/base/GHC/Records.hs libraries/base/GHC/ResponseFile.hs libraries/base/GHC/ST.hs libraries/base/GHC/STRef.hs libraries/base/GHC/Show.hs libraries/base/GHC/Stable.hs libraries/base/GHC/StableName.hs libraries/base/GHC/Stack.hs _validate- bug/stage1/libraries/base/build/GHC/Stack/CCS.hs libraries/base/GHC/Stack/Types.hs libraries/base/GHC/StaticPtr.hs libraries/base/GHC/StaticPtr/Internal.hs _validate- bug/stage1/libraries/base/build/GHC/Stats.hs libraries/base/GHC/Storable.hs libraries/base/GHC/TopHandler.hs libraries/base/GHC/TypeLits.hs libraries/base/GHC/TypeNats.hs libraries/base/GHC/Unicode.hs libraries/base/GHC/Weak.hs libraries/base/GHC/Word.hs libraries/base/Numeric.hs libraries/base/Numeric/Natural.hs libraries/base/Prelude.hs _validate- bug/stage1/libraries/base/build/System/CPUTime.hs _validate- bug/stage1/libraries/base/build/System/CPUTime/Posix/ClockGetTime.hs _validate-bug/stage1/libraries/base/build/System/CPUTime/Posix/RUsage.hs _validate-bug/stage1/libraries/base/build/System/CPUTime/Posix/Times.hs libraries/base/System/CPUTime/Unsupported.hs libraries/base/System/CPUTime/Utils.hs libraries/base/System/Console/GetOpt.hs libraries/base/System/Environment.hs _validate- bug/stage1/libraries/base/build/System/Environment/Blank.hs _validate- bug/stage1/libraries/base/build/System/Environment/ExecutablePath.hs libraries/base/System/Exit.hs libraries/base/System/IO.hs libraries/base/System/IO/Error.hs libraries/base/System/IO/Unsafe.hs libraries/base/System/Info.hs libraries/base/System/Mem.hs libraries/base/System/Mem/StableName.hs libraries/base/System/Mem/Weak.hs libraries/base/System/Posix/Internals.hs libraries/base/System/Posix/Types.hs libraries/base/System/Timeout.hs libraries/base/Text/ParserCombinators/ReadP.hs libraries/base/Text/ParserCombinators/ReadPrec.hs libraries/base/Text/Printf.hs libraries/base/Text/Read.hs libraries/base/Text/Read/Lex.hs libraries/base/Text/Show.hs libraries/base/Text/Show/Functions.hs libraries/base/Type/Reflection.hs libraries/base/Type/Reflection/Unsafe.hs libraries/base/Unsafe/Coerce.hs +RTS -t_validate-bug/stage1/libraries/base/build/haddock.t --machine- readable -RTS Warning: 'UAddr' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1025:40 * at libraries/base/GHC/Generics.hs:1094:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UAddr' defined at libraries/base/GHC/Generics.hs:1094:1 Warning: 'UChar' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1036:36 * at libraries/base/GHC/Generics.hs:1098:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UChar' defined at libraries/base/GHC/Generics.hs:1098:1 Warning: 'UDouble' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1048:38 * at libraries/base/GHC/Generics.hs:1103:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UDouble' defined at libraries/base/GHC/Generics.hs:1103:1 Warning: 'UFloat' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1060:37 * at libraries/base/GHC/Generics.hs:1108:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UFloat' defined at libraries/base/GHC/Generics.hs:1108:1 Warning: 'UInt' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1070:35 * at libraries/base/GHC/Generics.hs:1113:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UInt' defined at libraries/base/GHC/Generics.hs:1113:1 Warning: 'UWord' is ambiguous. It is defined * at libraries/base/GHC/Generics.hs:1082:36 * at libraries/base/GHC/Generics.hs:1118:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'UWord' defined at libraries/base/GHC/Generics.hs:1118:1 Warning: 'IOError' is ambiguous. It is defined * at libraries/base/GHC/IO/Exception.hs:331:4 * at libraries/base/GHC/IO/Exception.hs:324:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'IOError' defined at libraries/base/GHC/IO/Exception.hs:330:1 Warning: 'IOError' is ambiguous. It is defined * at libraries/base/GHC/IO/Exception.hs:331:4 * at libraries/base/GHC/IO/Exception.hs:324:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'IOError' defined at libraries/base/GHC/IO/Exception.hs:330:1 Warning: 'IOError' is ambiguous. It is defined * at libraries/base/GHC/IO/Exception.hs:331:4 * at libraries/base/GHC/IO/Exception.hs:324:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'IOError' defined at libraries/base/GHC/IO/Exception.hs:330:1 Warning: 'flock' is out of scope. If you qualify the identifier, haddock can try to link it anyway. Warning: 'LockFileEx' is out of scope. If you qualify the identifier, haddock can try to link it anyway. Warning: 'FileLockingNotImplemented' is out of scope. If you qualify the identifier, haddock can try to link it anyway. Warning: 'IOError' is ambiguous. It is defined * at libraries/base/GHC/IO/Exception.hs:331:4 * at libraries/base/GHC/IO/Exception.hs:324:1 You may be able to disambiguate the identifier by qualifying it or by hiding some imports. Defaulting to 'IOError' defined at libraries/base/GHC/IO/Exception.hs:330:1 Warning: 'ExitException' is out of scope. If you qualify the identifier, haddock can try to link it anyway. Warning: 'mtimes' is out of scope. If you qualify the identifier, haddock can try to link it anyway. Warning: GHC.Word: could not find link destinations for: D:R:UReckWordp0 Warning: GHC.Float: could not find link destinations for: D:R:UReckFloatp0 D:R:UReckDoublep0 Warning: Text.Read.Lex: could not find link destinations for: guard Warning: GHC.Ptr: could not find link destinations for: D:R:UReckPtrp0 Warning: GHC.Int: could not find link destinations for: D:R:UReckIntp0 Warning: Data.Int: could not find link destinations for: D:R:UReckIntp0 Warning: Foreign.Ptr: could not find link destinations for: D:R:UReckPtrp0 Warning: Data.Word: could not find link destinations for: D:R:UReckWordp0 Warning: Data.Type.Equality: could not find link destinations for: ~# Warning: Data.Char: could not find link destinations for: D:R:UReckCharp0 Warning: GHC.TypeNats: could not find link destinations for: natSing Warning: GHC.TypeLits: could not find link destinations for: natSing symbolSing Warning: GHC.Generics: could not find link destinations for: D:R:UReckWordp0 D:R:UReckIntp0 D:R:UReckFloatp0 D:R:UReckDoublep0 D:R:UReckCharp0 D:R:UReckPtrp0 SingI SingKind Warning: Type.Reflection: could not find link destinations for: typeRep# IsApplication Warning: Data.Typeable: could not find link destinations for: typeRep# Warning: GHC.IO: could not find link destinations for: hspr UPrintf spr Warning: GHC.ForeignPtr: could not find link destinations for: Finalizers Warning: GHC.Foreign: could not find link destinations for: CString CStringLen Warning: Data.Dynamic: could not find link destinations for: typeRep# Warning: System.IO: could not find link destinations for: hspr UPrintf spr Warning: Prelude: could not find link destinations for: D:R:UReckCharp0 D:R:UReckIntp0 D:R:UReckFloatp0 D:R:UReckDoublep0 D:R:UReckWordp0 hspr UPrintf spr Warning: Text.Printf: could not find link destinations for: spr UPrintf hspr Warning: GHC.ExecutionStack.Internal: could not find link destinations for: locationSize Warning: GHC.Exts: could not find link destinations for: D:R:UReckIntp0 D:R:UReckWordp0 D:R:UReckFloatp0 D:R:UReckDoublep0 D:R:UReckCharp0 D:R:UReckPtrp0 ~# shakeArgsWith 0.000s 0% Function shake 0.005s 0% Database read 0.479s 0% With database 0.037s 0% Running rules 62.764s 99% ========================= Total 63.285s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: _validate-bug/docs/html/libraries/base/base.haddock * Raised the exception: user error (Development.Shake.cmd, system command failed Command: _validate-bug/stage1/bin/haddock --verbosity=0 -B_validate- bug/stage1/lib --lib=_validate-bug/stage1/lib --odir=_validate- bug/docs/html/libraries/base --no-tmp-comp-dir --dump-interface=_validate- bug/docs/html/libraries/base/base.haddock --html --hyperlinked-source --hoogle --quickjump '--title=base-4.12.0.0: Basic libraries' --prologue =_validate-bug/docs/html/libraries/base/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2220 --hide=Control.Monad.ST.Imp --hide=Control.Monad.ST.Lazy.Imp --hide=Data.Functor.Utils --hide=Data.OldList --hide=Data.Semigroup.Internal --hide=Data.Typeable.Internal --hide=Foreign.ForeignPtr.Imp --hide=GHC.StaticPtr.Internal --hide=System.Environment.ExecutablePath --hide=System.CPUTime.Utils --hide=GHC.Event.Arr --hide=GHC.Event.Array --hide=GHC.Event.Control --hide=GHC.Event.EPoll --hide=GHC.Event.IntTable --hide=GHC.Event.Internal --hide=GHC.Event.KQueue --hide=GHC.Event.Manager --hide=GHC.Event.PSQ --hide=GHC.Event.Poll --hide=GHC.Event.Thread --hide=GHC.Event.TimerManager --hide=GHC.Event.Unique --hide=System.CPUTime.Posix.ClockGetTime --hide=System.CPUTime.Posix.Times --hide=System.CPUTime.Posix.RUsage --hide=System.CPUTime.Unsupported --read-interface=../ghc-prim,../ghc-prim/src/%{MODULE}.html#%{NAME },_validate-bug/docs/html/libraries/ghc-prim/ghc-prim.haddock --read- interface=../integer-gmp,../integer-gmp/src/%{MODULE}.html#%{NAME },_validate-bug/docs/html/libraries/integer-gmp/integer-gmp.haddock --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc =-hide-all-packages --optghc=-no-user-package-db '--optghc=-this-unit-id base-4.12.0.0' '--optghc=-package-id ghc-prim-0.5.3' '--optghc=-package-id integer-gmp-1.0.2.0' '--optghc=-package-id rts-1.0' --optghc=-i --optghc =-i_validate-bug/stage1/libraries/base/build --optghc=-i_validate- bug/stage1/libraries/base/build/autogen --optghc=-ilibraries/base/. --optghc=-Iincludes --optghc=-I_validate-bug/generated --optghc =-I_validate-bug/stage1/libraries/base/build --optghc=-I/nix/store /jxaaf8dsrb16vnwnij69jar7mhhj969q-ghc-build-environment/include --optghc =-I_validate-bug/stage1/libraries/base/build/include --optghc=-Ilibraries/base/include --optghc=-I/nix/store /jxaaf8dsrb16vnwnij69jar7mhhj969q-ghc-build-environment/include --optghc=-I/home/alp/WT/ghc-gitlab/_validate-bug/stage1/lib/x86_64-linux- ghc-8.7.20190123/integer-gmp-1.0.2.0/include --optghc=-I/home/alp/WT/ghc- gitlab/_validate-bug/stage1/lib/x86_64-linux- ghc-8.7.20190123/rts-1.0/include --optghc=-I_validate-bug/generated --optghc=-optc-I_validate-bug/generated --optghc=-optP-include --optghc =-optP_validate-bug/stage1/libraries/base/build/autogen/cabal_macros.h --optghc=-outputdir --optghc=_validate-bug/stage1/libraries/base/build --optghc=-this-unit-id --optghc=base --optghc=-Wcompat --optghc =-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc =-ghcversion-file=/home/alp/WT/ghc-gitlab/_validate- bug/generated/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno- trustworthy-safe libraries/base/Control/Applicative.hs libraries/base/Control/Arrow.hs libraries/base/Control/Category.hs libraries/base/Control/Concurrent.hs libraries/base/Control/Concurrent/Chan.hs libraries/base/Control/Concurrent/MVar.hs libraries/base/Control/Concurrent/QSem.hs libraries/base/Control/Concurrent/QSemN.hs libraries/base/Control/Exception.hs libraries/base/Control/Exception/Base.hs libraries/base/Control/Monad.hs libraries/base/Control/Monad/Fail.hs libraries/base/Control/Monad/Fix.hs libraries/base/Control/Monad/IO/Class.hs libraries/base/Control/Monad/Instances.hs libraries/base/Control/Monad/ST.hs libraries/base/Control/Monad/ST/Imp.hs libraries/base/Control/Monad/ST/Lazy.hs libraries/base/Control/Monad/ST/Lazy/Imp.hs libraries/base/Control/Monad/ST/Lazy/Safe.hs libraries/base/Control/Monad/ST/Lazy/Unsafe.hs libraries/base/Control/Monad/ST/Safe.hs libraries/base/Control/Monad/ST/Strict.hs libraries/base/Control/Monad/ST/Unsafe.hs libraries/base/Control/Monad/Zip.hs libraries/base/Data/Bifoldable.hs libraries/base/Data/Bifunctor.hs libraries/base/Data/Bitraversable.hs libraries/base/Data/Bits.hs libraries/base/Data/Bool.hs libraries/base/Data/Char.hs libraries/base/Data/Coerce.hs libraries/base/Data/Complex.hs libraries/base/Data/Data.hs libraries/base/Data/Dynamic.hs libraries/base/Data/Either.hs libraries/base/Data/Eq.hs libraries/base/Data/Fixed.hs libraries/base/Data/Foldable.hs libraries/base/Data/Function.hs libraries/base/Data/Functor.hs libraries/base/Data/Functor/Classes.hs libraries/base/Data/Functor/Compose.hs libraries/base/Data/Functor/Const.hs libraries/base/Data/Functor/Contravariant.hs libraries/base/Data/Functor/Identity.hs libraries/base/Data/Functor/Product.hs libraries/base/Data/Functor/Sum.hs libraries/base/Data/Functor/Utils.hs libraries/base/Data/IORef.hs libraries/base/Data/Int.hs libraries/base/Data/Ix.hs libraries/base/Data/Kind.hs libraries/base/Data/List.hs libraries/base/Data/List/NonEmpty.hs libraries/base/Data/Maybe.hs libraries/base/Data/Monoid.hs libraries/base/Data/OldList.hs libraries/base/Data/Ord.hs libraries/base/Data/Proxy.hs libraries/base/Data/Ratio.hs libraries/base/Data/STRef.hs libraries/base/Data/STRef/Lazy.hs libraries/base/Data/STRef/Strict.hs libraries/base/Data/Semigroup.hs libraries/base/Data/Semigroup/Internal.hs libraries/base/Data/String.hs libraries/base/Data/Traversable.hs libraries/base/Data/Tuple.hs libraries/base/Data/Type/Bool.hs libraries/base/Data/Type/Coercion.hs libraries/base/Data/Type/Equality.hs libraries/base/Data/Typeable.hs libraries/base/Data/Typeable/Internal.hs libraries/base/Data/Unique.hs libraries/base/Data/Version.hs libraries/base/Data/Void.hs libraries/base/Data/Word.hs libraries/base/Debug/Trace.hs libraries/base/Foreign.hs libraries/base/Foreign/C.hs libraries/base/Foreign/C/Error.hs libraries/base/Foreign/C/String.hs libraries/base/Foreign/C/Types.hs libraries/base/Foreign/Concurrent.hs libraries/base/Foreign/ForeignPtr.hs libraries/base/Foreign/ForeignPtr/Imp.hs libraries/base/Foreign/ForeignPtr/Safe.hs libraries/base/Foreign/ForeignPtr/Unsafe.hs libraries/base/Foreign/Marshal.hs libraries/base/Foreign/Marshal/Alloc.hs libraries/base/Foreign/Marshal/Array.hs libraries/base/Foreign/Marshal/Error.hs libraries/base/Foreign/Marshal/Pool.hs libraries/base/Foreign/Marshal/Safe.hs libraries/base/Foreign/Marshal/Unsafe.hs libraries/base/Foreign/Marshal/Utils.hs libraries/base/Foreign/Ptr.hs libraries/base/Foreign/Safe.hs libraries/base/Foreign/StablePtr.hs libraries/base/Foreign/Storable.hs libraries/base/GHC/Arr.hs libraries/base/GHC/Base.hs libraries/base/GHC/ByteOrder.hs libraries/base/GHC/Char.hs _validate- bug/stage1/libraries/base/build/GHC/Clock.hs libraries/base/GHC/Conc.hs libraries/base/GHC/Conc/IO.hs libraries/base/GHC/Conc/Signal.hs libraries/base/GHC/Conc/Sync.hs libraries/base/GHC/ConsoleHandler.hs libraries/base/GHC/Constants.hs libraries/base/GHC/Desugar.hs libraries/base/GHC/Enum.hs libraries/base/GHC/Environment.hs libraries/base/GHC/Err.hs libraries/base/GHC/Event.hs libraries/base/GHC/Event/Arr.hs libraries/base/GHC/Event/Array.hs libraries/base/GHC/Event/Control.hs _validate- bug/stage1/libraries/base/build/GHC/Event/EPoll.hs libraries/base/GHC/Event/IntTable.hs libraries/base/GHC/Event/Internal.hs _validate-bug/stage1/libraries/base/build/GHC/Event/KQueue.hs libraries/base/GHC/Event/Manager.hs libraries/base/GHC/Event/PSQ.hs _validate-bug/stage1/libraries/base/build/GHC/Event/Poll.hs libraries/base/GHC/Event/Thread.hs libraries/base/GHC/Event/TimerManager.hs libraries/base/GHC/Event/Unique.hs libraries/base/GHC/Exception.hs libraries/base/GHC/Exception/Type.hs libraries/base/GHC/ExecutionStack.hs _validate-bug/stage1/libraries/base/build/GHC/ExecutionStack/Internal.hs libraries/base/GHC/Exts.hs libraries/base/GHC/Fingerprint.hs libraries/base/GHC/Fingerprint/Type.hs libraries/base/GHC/Float.hs libraries/base/GHC/Float/ConversionUtils.hs libraries/base/GHC/Float/RealFracMethods.hs libraries/base/GHC/Foreign.hs libraries/base/GHC/ForeignPtr.hs libraries/base/GHC/GHCi.hs libraries/base/GHC/Generics.hs libraries/base/GHC/IO.hs libraries/base/GHC/IO/Buffer.hs libraries/base/GHC/IO/BufferedIO.hs libraries/base/GHC/IO/Device.hs libraries/base/GHC/IO/Encoding.hs libraries/base/GHC/IO/Encoding/CodePage.hs libraries/base/GHC/IO/Encoding/Failure.hs libraries/base/GHC/IO/Encoding/Iconv.hs libraries/base/GHC/IO/Encoding/Latin1.hs libraries/base/GHC/IO/Encoding/Types.hs libraries/base/GHC/IO/Encoding/UTF16.hs libraries/base/GHC/IO/Encoding/UTF32.hs libraries/base/GHC/IO/Encoding/UTF8.hs libraries/base/GHC/IO/Exception.hs libraries/base/GHC/IO/FD.hs libraries/base/GHC/IO/Handle.hs libraries/base/GHC/IO/Handle/FD.hs libraries/base/GHC/IO/Handle/Internals.hs _validate- bug/stage1/libraries/base/build/GHC/IO/Handle/Lock.hs libraries/base/GHC/IO/Handle/Text.hs libraries/base/GHC/IO/Handle/Types.hs libraries/base/GHC/IO/IOMode.hs libraries/base/GHC/IO/Unsafe.hs libraries/base/GHC/IOArray.hs libraries/base/GHC/IORef.hs libraries/base/GHC/Int.hs libraries/base/GHC/List.hs libraries/base/GHC/MVar.hs libraries/base/GHC/Maybe.hs libraries/base/GHC/Natural.hs libraries/base/GHC/Num.hs libraries/base/GHC/OldList.hs libraries/base/GHC/OverloadedLabels.hs libraries/base/GHC/Pack.hs libraries/base/GHC/Profiling.hs libraries/base/GHC/Ptr.hs _validate- bug/stage1/libraries/base/build/GHC/RTS/Flags.hs libraries/base/GHC/Read.hs libraries/base/GHC/Real.hs libraries/base/GHC/Records.hs libraries/base/GHC/ResponseFile.hs libraries/base/GHC/ST.hs libraries/base/GHC/STRef.hs libraries/base/GHC/Show.hs libraries/base/GHC/Stable.hs libraries/base/GHC/StableName.hs libraries/base/GHC/Stack.hs _validate- bug/stage1/libraries/base/build/GHC/Stack/CCS.hs libraries/base/GHC/Stack/Types.hs libraries/base/GHC/StaticPtr.hs libraries/base/GHC/StaticPtr/Internal.hs _validate- bug/stage1/libraries/base/build/GHC/Stats.hs libraries/base/GHC/Storable.hs libraries/base/GHC/TopHandler.hs libraries/base/GHC/TypeLits.hs libraries/base/GHC/TypeNats.hs libraries/base/GHC/Unicode.hs libraries/base/GHC/Weak.hs libraries/base/GHC/Word.hs libraries/base/Numeric.hs libraries/base/Numeric/Natural.hs libraries/base/Prelude.hs _validate- bug/stage1/libraries/base/build/System/CPUTime.hs _validate- bug/stage1/libraries/base/build/System/CPUTime/Posix/ClockGetTime.hs _validate-bug/stage1/libraries/base/build/System/CPUTime/Posix/RUsage.hs _validate-bug/stage1/libraries/base/build/System/CPUTime/Posix/Times.hs libraries/base/System/CPUTime/Unsupported.hs libraries/base/System/CPUTime/Utils.hs libraries/base/System/Console/GetOpt.hs libraries/base/System/Environment.hs _validate- bug/stage1/libraries/base/build/System/Environment/Blank.hs _validate- bug/stage1/libraries/base/build/System/Environment/ExecutablePath.hs libraries/base/System/Exit.hs libraries/base/System/IO.hs libraries/base/System/IO/Error.hs libraries/base/System/IO/Unsafe.hs libraries/base/System/Info.hs libraries/base/System/Mem.hs libraries/base/System/Mem/StableName.hs libraries/base/System/Mem/Weak.hs libraries/base/System/Posix/Internals.hs libraries/base/System/Posix/Types.hs libraries/base/System/Timeout.hs libraries/base/Text/ParserCombinators/ReadP.hs libraries/base/Text/ParserCombinators/ReadPrec.hs libraries/base/Text/Printf.hs libraries/base/Text/Read.hs libraries/base/Text/Read/Lex.hs libraries/base/Text/Show.hs libraries/base/Text/Show/Functions.hs libraries/base/Type/Reflection.hs libraries/base/Type/Reflection/Unsafe.hs libraries/base/Unsafe/Coerce.hs +RTS -t_validate-bug/stage1/libraries/base/build/haddock.t --machine- readable -RTS Exit code: -11 Stderr: ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 19:05:26 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 19:05:26 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.f58037d7d5c33fa57a70fbfe1ec0b6b2@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Indeed changing the last line from: {{{ f line locker }}} to {{{ ret <- f line locker return ret }}} resolves the bug for my code example. I hope this generalizes. Don't know how it applies to the original parallel list comprehension example. I did not expect the "where" alternative to generalize, but note that in this case I was able to arrange for all the relevant variables to be in scope by passing them into a closure precisely for that purpose. The idea was mostly to highlight the discrepancy in the behaviour between a "let" and a "where" that should ideally behave identically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 19:31:40 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 19:31:40 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.bc3ddb9a243164c42df66220721f9e12@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Oh no, looks like Haddock is segfaulting. Every time this has happened so far, it was due to some improper use of unsafe GHC internals. Are there any more specific instructions for reproducing this (or maybe even a failing CI job)? I've been successfully running Haddock benchmarks through Hadrian all morning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 20:40:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 20:40:45 -0000 Subject: [GHC] #16238: Hadrian provides no way to accept output of test In-Reply-To: <049.1873139ea1b4f6b0248689aa8bba7e65@haskell.org> References: <049.1873139ea1b4f6b0248689aa8bba7e65@haskell.org> Message-ID: <064.d35b3e50c90b3ce690ce5cf4ac50290e@haskell.org> #16238: Hadrian provides no way to accept output of test -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 20:41:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 20:41:49 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values Message-ID: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- currently the way we write haskell code to handle multiple platforms or configurations use the C preprocessor (CPP) in traditional mode. there are several challenges with this 1) tooling dependency 2) not actually designed for haskell code 3) no compiler support for checking the syntax / name / type well- formedness of each alternative code fragment under the associated environment assumptions. Abstractly, CPP uses a mapping from Names to Maybe (Either String Integer) or something to that effect. theres two ways we could then treat a "HPP" design: 1) just like CPP traditional mode, its just splicing tokens together. a) One implication of this design choice would be that to be able to check/ parse the different combinations of compilation, you'd need to be able to enumerate the set of maps of key value pairs of interest, and then you'd roughly want to have each Module be actually a {{{ Map (Map String (Maybe (Either String Integer))) Module) }}} this would have some pretty obvious code blowup issues, at least if you wanted to full on type check each combination in full. 2) only allow "HPP" to work on valid syntactic units, eg expressions, right hand sides, patterns, top level definition, etc, and provide a magic primop or several that would look roughly like NOTE: it could also just be at the Haskell post type inference phase, not necessarily at core level {{{ DefinitionDispatchTermLevel :: [(Map String (Maybe (Either String Integer)) , CoreTerm)] -> --- set of all #if/else/ifdef etc conditionals? Map (String) (Maybe (Either String Integer)) -> -- actual CPP flag combination used CoreTerm -> --- actual term ghc / optimizer works with and manipulates CoreTerm }}} this sketched out constructor representation overlooks a few things, eg the ability to do interval predicates and various boolean algebra operations, which WOULD be expressible in a fully fleshed out approch to this, but i'm elliding to keep simple. i think approach (1) or something like it would have the benefit of mostly working "today" wrt how we use CPP, and checking/coverage could be done via some package level or module level enumeration of cpp value mappings that you wnat to be checked or even generated approach (2) adds a funny looking operation to core/haskell terms/types representation where you could carry around "alternative expressions" plus the "selected expression". and thus you could do some amount of syntax/type checking for those altnerative platforms? either way, this is just me jotting down some thoughts on this because its been discussed on and off for a while now as an eventual nice to have for ghc. Also quite a complicated design space! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 20:49:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 20:49:29 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.4f1dc7b0967a9760677c1befd298fa26@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I use https://github.com/alpmestan/ghc.nix to provide a build environment and launch a simple command to build that haddock target: {{{ #!sh $ nix-shell path/to/ghc.nix/ --run './boot && ./configure; hadrian/build.sh -o_foo -V -j4 _foo/docs/html/libraries/base/base.haddock' }}} should do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 21:05:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 21:05:49 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.936461a0be21049936a2d900b3383bcc@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): forgot to add: each map assignment would correspond to a different typing environment if we wanted to check types under each combination .. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 21:12:48 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 21:12:48 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.aa7f0779fa00985a4d613b4517bf42b6@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:1 carter]: > forgot to add: each map assignment would correspond to a different typing environment if we wanted to check types under each combination .. There are valid use cases for CPP with code which doesn't compile/type check at all under one of the variants on a specific system. Primarily when libraries/ghc add new features and only the old version is available. Eg I don't see how this would be enough if a base version uses a different class definition for Monoid. You would need both definitions to type check both variants, which in general is not always possible. So ideally we want to support both: * Essentially string replacement * Typechecking of both variants. Unless you want to restrict HPP to certain use cases and fall back to CPP for other ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 21:14:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 21:14:30 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.02551c549b650e568d075e5518fef8d8@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | CPRAnalysis, DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Is there a merge request or differential with Sebastian's work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 21:19:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 21:19:51 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.e0de2d612230e4e9dc0c7dfeaf258b2f@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): agreed. I think "new style HPP" would probably involve ghc understanding that the predicates around eg GHC version and package version are "externally fixed" and cant be fudged/checked under a single GHC environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 22:15:46 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 22:15:46 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.9ca625c705d650343329486b02ce53bf@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are two different things going on here. First, for the program in the Description, there is really no difficulty in principle. The relevant code is in `TcMatches`: {{{ tcMcStmt ctxt (ParStmt _ bndr_stmts_s mzip_op bind_op) res_ty thing_inside = do { let star_star_kind = liftedTypeKind `mkFunTy` liftedTypeKind ; m_ty <- newFlexiTyVarTy star_star_kind ... }}} We have to generate code something like {{{ (mzip >>= \((f,y), x) -> return (f y True, f x 'c') }}} Now, the trouble is that `f` is polymophic, so we need to build a tuple with polymorphic components, ''and'' we must instantiate `>>=` at a polymoprhic type. Neither of these is truly problematic -- GHC's internal language supports impredicative polymorphism, and there is really no difficulty with figuring out where the polymorphism is. But in fact the instantiation of `(>>=)` goes through the notorious `tcSyntaxOp`, which is currently a bug-farm with several open tickets. This ticket points out that `tcSyntaxOp` should really be capable of impredicative instantiation. But currently it is not. Work needed -- but much easier that full support for impredicative polymorphism. Second, for the program in comment:5, as josef points out in comment:11, the ''renamer'' rewrites the program to a form that really would require full-on impredicative polymorphism to propagate `f`'s polymorphism. This is really very naughty: the typechecker is supposed to typecheck the program the user originally wrote -- and here is a fine example of why that is a good principle. I think the solution here is for the renamer to annotate with applicative- do info, but not really rewrite it. Then we can typecheck it directly, rather than typechecking a rewritten form. The exact design of this is beyond the puny limits of my brain right now, but that smells like the right direction. I'd be happy to advise, esp on the first bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 22:24:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 22:24:39 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.7197d81a89c7bfbca0ca09a2d42b9f9e@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | CPRAnalysis, DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Not yet, but it's high on my todo list. See https://phabricator.haskell.org/D4244#126311 for the last attempt; I'll prepare a wiki page with a proper motivation for why I think it's best to split off CPR analysis and then reimplement the nested CPR idea on top. Actually, the CPRing sums idea is rather orthogonal, so I can probably cook that up first... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:28:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:28:36 -0000 Subject: [GHC] #16224: CPUTime001 is fragile In-Reply-To: <046.14e27fa680beb0296780580789b4c71d@haskell.org> References: <046.14e27fa680beb0296780580789b4c71d@haskell.org> Message-ID: <061.c958c2380e7bff6da125d438779941e2@haskell.org> #16224: CPUTime001 is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:30:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:30:42 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.86ad784a55261e9ebf80d17c3b592e3b@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:31:19 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:31:19 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.1f40a542a87d36bfd364181b30263584@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16204, #16225 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:40:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:40:10 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.f18dd26692c442ec97a80b3b80e3c919@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): https://gitlab.haskell.org/ghc/ghc/merge_requests/219 might address this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:40:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:40:28 -0000 Subject: [GHC] #12364: Demand analysis for sum types In-Reply-To: <046.d2210fe5d78e7148b495c8c2b1cf9322@haskell.org> References: <046.d2210fe5d78e7148b495c8c2b1cf9322@haskell.org> Message-ID: <061.3558f7a72340d1bf0958a16cb9c68964@haskell.org> #12364: Demand analysis for sum types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | DemandAnalysis CPRAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * keywords: => DemandAnalysis CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:44:18 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:44:18 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.f95b7c9f6edaca0e70bd795c99b6e9d9@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/219 -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/219 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:55:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:55:13 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.70ce0e8ea78b764fe39691bc20afe689@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill | panic impossible Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash | http://hackage.haskell.org/package/SHA Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): This will be properly fixed when https://gitlab.haskell.org/ghc/ghc/merge_requests/219 lands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 25 23:56:18 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Jan 2019 23:56:18 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.553b0d0d71438ee8e067b79653ee22a5@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Yes, I think I was a bit too bold in declaring comment:23 to be a viable workaround (in fact, I'm now discovering places in the aforementioned large codebase where this technique breaks down). A much uglier (but likelier to work in the long run) hack is to add another parameter to `C`: {{{#!hs class (forall b. (ta ~ T a, Show b) => Show (ta b)) => C a ta where type family T a :: * -> * data D a = MkD (T a Int) deriving instance (ta ~ T a, C a ta) => Show (D a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 01:13:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 01:13:09 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.4295c9fc325da795c9272fef73582093@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): I'm running into https://github.com/NixOS/nixpkgs/issues/28997 trying to replicate. Do let me know if you manage to replicate this anywhere else. Otherwise, it would be nice to know if building without `--html` and `--hyperlinked-source` still segfaults. Same thing for building with `--html` and without `--hyperlinked-source`. As part of the HIE hyperlinker work, I've gotten rid of some of the old `StringBuffer`-related segfault footguns Haddock used to have, so this might even be fixed on that branch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 09:41:31 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 09:41:31 -0000 Subject: [GHC] #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) Message-ID: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #15135 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure whether to count this as a bug or a feature. If it's 'intended behaviour', what is the intent, exactly? GHC is on the verge of doing something useful, but it's inconsistent and "fragile" (as the warning does tell me). Consider the standard example of what goes wrong with orphan instances, from the [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts.html #overlapping-instances big red **warning** in the Users Guide]. (Version 1 lightly adapted to use `OVERLAPPING` rather than the now-deprecated `Overlapping Instances`.) {{{#!hs {-# LANGUAGE FlexibleInstances, FlexibleContexts #-} module Help where class MyShow a where myshow :: a -> String instance MyShow a => MyShow [a] where -- version 1 -- instance {-# OVERLAPPABLE #-} -- version 2 -- MyShow a => MyShow [a] where myshow xs = concatMap myshow xs showHelp :: MyShow a => [a] -> String -- version 1 -- showHelp :: MyShow [a] => [a] -> String -- version 2 showHelp xs = myshow xs {-# LANGUAGE FlexibleInstances #-} module Main where import Help data T = MkT instance MyShow T where myshow x = "Used generic instance" instance {# OVERLAPPING #} MyShow [T] where myshow xs = "Used more specific instance" main = do { print (myshow [MkT]); print (showHelp [MkT]) } }}} Version 1 gives the as-warned incoherent behaviour ("different instance choices are made in different parts of the program" -- that is, in different modules for the (apparently) same code `myshow xs`.) If and only if both changes marked `version 2` are in place, `myshow xs` returns the same result from both calls consistently. Why? Because the `MyShow [a] =>` constraint on `showHelp`'s sig sees that exactly matches an instance head, and that the head is marked `OVERLAPPABLE`. But GHC is not happy {{{ ... warning: [-Wsimplifiable-class-constraints] * The constraint `MyShow [a]' matches an instance declaration instance [overlappable] MyShow a => MyShow [a] This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance }}} Hmm: wrong advice: simplifying the constraint using the instance gives us the version 1 signature, which exactly makes `showHelp` use the orphan instance. ''Does'' version 2 make inference for inner bindings fragile? I think only if the instance is not marked `OVERLAPPABLE`. IOW a tentative rule would be 'OVERLAPPABLE constraints should not be simplified!' Inconsistencies I see: * Marking overlappable instances as `OVERLAPPABLE` is not merely the mirror-image of marking the overlapping instance as `OVERLAPPING`: you get different behaviour. * The `OVERLAPPABLE` pragma, when you already have `OVERLAPPING` to accept the instances, is not merely a comment. * This makes an observable difference under separate compilation, contra SPJ's ticket:15135#comment:9 . * ticket:15135#comment:1 is also relevant "I think it's arguable that an instance should only be overlappable if it says `{-# OVERLAPPABLE #-}`. But that's not our current spec." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 10:45:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 10:45:15 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.62e3b3340b5bf15634739e69690d2bef@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | CPRAnalysis, DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:9 sgraf]: > Actually, the CPRing sums idea is rather orthogonal, so I can probably cook that up first... Nope, I realised that a useful CPR for sums needs CPR of depth > 1, so I'll pursue the nested CPR idea and all that comes with it first. The wiki page for why splitting off CPR is a good thing is wiki:NestedCPR/SplitOffCPR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 10:48:12 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 10:48:12 -0000 Subject: [GHC] #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. In-Reply-To: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> References: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> Message-ID: <062.5afcb6d20d7628aacc6b23e88a3f6686@haskell.org> #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * priority: normal => high Comment: No, it's affecting all shells, the only reason it "works" in msys is because msys2 has it's own copy of `libgmp-10.dll` which it puts on the PATH. But this gmp is there for GCC's use not GHC, on Windows `gmp` is supposed to be statically linked using `libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-intree-gmp` which Make sets. TL;DR: Hadrian builds integer-gmp incorrectly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 10:50:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 10:50:34 -0000 Subject: [GHC] #16144: Provide integer-simple builds on Windows. (was: GHC with valid license on windows) In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.be86b6158bc733887a19013c3bd78f7a@haskell.org> #16144: Provide integer-simple builds on Windows. -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * keywords: incorrect license on windows => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 10:52:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 10:52:32 -0000 Subject: [GHC] #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. In-Reply-To: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> References: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> Message-ID: <062.db0f7ca85c2ab4183c07666ecabf0d90@haskell.org> #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: snowleopard, alpmesta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 14:18:26 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 14:18:26 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.c2697bf89c6bf2b154a40a63d833bad4@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15884, #16129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) Comment: Given that it takes so little to run into this bug (see comment:8), should its priority maybe be `high` instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 15:21:42 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 15:21:42 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding Message-ID: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's what has happened: 1. `build` (with settings `devel2`). This did its thing successfully. 2. Edit a comment in one file. 3. `build test --only=blahblahblah`. I was expecting to run a test. (It was a new test-case, a change unrelated to the comment I fixed.) What happens though is that stage-1 is rebuilt, and now I'm currently waiting for the entire RTS to be rebuilt. And all I wanted to do is run a test! I understand why Hadrian is doing this; it's technically got the upper hand here. But it's very frustrating. I suppose I could have done `--freeze1`, but it's too late now. And, even if I didn't do `--freeze1`, I'm surprised that the whole RTS needs to be rebuilt. Again, I know why Hadrian wants to. But I miss the old `LAX_DEPENDENCIES` feature of `make`. So, I suppose this boils down to two requests: 1. Restore the `LAX_DEPENDENCIES` feature. I don't know the specification of that feature, but my experience is that it just did the Right Thing, and I always had it enabled (except during validation). 2. Have some way of just running a test, without any rebuilding. Somewhat separately, it might be nice to package up common idioms into smaller command lines. Again, individual devs can do this, but centralized support (especially so that these scripts can be run from a variety of directories) would be nice. For example, I imagine my suggestion (2) above will lead to `build test --no-recompilation --only=xyz`, but that's a long line to write! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 26 15:55:48 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Jan 2019 15:55:48 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.895c419ba181bbe98710aabb819d3145@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14729 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 00:29:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 00:29:23 -0000 Subject: [GHC] #16243: Improve fregs-graph. Message-ID: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> #16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: fregs-graph | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm creating this as a way to keep track of shortcomings of the current implementation. Some of these are directly taken from TODOS, other are my own opinions. = Things that could be looked at. == Compress spill slots. Currently we assign each vreg a fixed spill slot. This is terrible for cache performance. It's possible to end up with sequences like this: {{{#!asm block_ca01_info: _ca01: movq 16(%rbp),%r14 movq 24(%rbp),%rax movq %rax,144(%rsp) movq 32(%rbp),%rsi movq 40(%rbp),%rdi movq 64(%rbp),%rbx movq 56(%rbp),%rax movq %rax,208(%rsp) movq 48(%rbp),%rax movq %rax,168(%rsp) movq 8(%rbp),%rax movq %rax,216(%rsp) addq $8,%rbp }}} Which splits spill slots over multiple cache lines increasing cache pressure. Things possibly worth trying: * Assign spill slots in the order they appear - hopefully reducing the average spread within code blocks. * Dynamically assign vregs to spill slots. For the later if we have large independent subgraphs we will sometimes get away with using far fewer slots. The reason simply being that non overlapping vregs can share spill slots. Doing this in an efficient manner however isn't easy. == We sometimes load + spill vregs when we could use memory addressing. One example I've seen a few times in nofib is this: {{{ movq 208(%rsp),%rax incq %rax movq %rax,208(%rsp) }}} Which we should replace with a single `inc` operating on memory. == Lift the stack size limit. There is already a patch [https://gitlab.haskell.org/ghc/ghc/merge_requests/219 in flight]. == Revisit spill costs. Currently the allocator always spills the longest live range. Which often works but is certainly not a great metric. Ideas: === Consider loop membership. At least for x86/64 this would be easy to achieve on basic block granularity using the CFG that is also used for block layout. === Revisit chaitins cost model. There have been major changes to cpus (amd64 becoming the norm) and the backend so at a minimum this cost model should be reevaluated. == Try splitting long live ranges instead of simply spilling the complete live range. After all long live ranges were the original reason to switch to a life range only based cost heuristic. == Use a different spill algorithm altogether. Maybe Chows live range splitting based approach would be an option. See "The priority based coloring approach to register allocation" for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 00:39:42 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 00:39:42 -0000 Subject: [GHC] #15621: Error message involving type families points to wrong location In-Reply-To: <050.f6fd8f38eae3af90b1d1147a0e35ac2c@haskell.org> References: <050.f6fd8f38eae3af90b1d1147a0e35ac2c@haskell.org> Message-ID: <065.68590d3cba004acb5ca45779b402d5b0@haskell.org> #15621: Error message involving type families points to wrong location -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): One more example, figuring out why ghc complains on an innocent looking line took a bit of time. {{{ % cat foo.hs }}} {{{#!haskell module P (o_O) where import GHC.Types o_O :: Maybe Any o_O = do present <- pure True if present then undefined :: Maybe Int else undefined :: Maybe Int }}} {{{ % ghc -O foo.hs [1 of 1] Compiling P ( foo.hs, foo.o ) foo.hs:7:5: error: • Couldn't match type ‘Any’ with ‘Int’ Expected type: Maybe Any Actual type: Maybe Int • In a stmt of a 'do' block: present <- pure True In the expression: do present <- pure True if present then undefined :: Maybe Int else undefined :: Maybe Int In an equation for ‘o_O’: o_O = do present <- pure True if present then undefined :: Maybe Int else undefined :: Maybe Int | 7 | present <- pure True | ^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 05:39:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 05:39:20 -0000 Subject: [GHC] #9173: Improve type mismatch error messages (was: Better type error messages) In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.81204a5c6e7bd8769851cac7f7528a85@haskell.org> #9173: Improve type mismatch error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nineonine): Sorry for the delay - had to face life! I opened MR here: https://gitlab.haskell.org/ghc/ghc/merge_requests/223 I also added a note there that will be converted to a wiki page in the future. Suggestions and comments are welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 05:53:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 05:53:01 -0000 Subject: [GHC] #13512: GHC incorrectly warns that a variable used in a type application is unused In-Reply-To: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> References: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> Message-ID: <065.30ff4e1667980ba4ea842d39ad502fec@haskell.org> #13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: sighingnow => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 14:30:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 14:30:38 -0000 Subject: =?utf-8?b?W0dIQ10gIzE2MjQ0OiBDb3VsZG4ndCBtYXRjaCBraW5kIOKAmGsx?= =?utf-8?b?4oCZIHdpdGgg4oCYazHigJk=?= Message-ID: <050.95ad1551395cf4b43b9d89c28dc7e1d8@haskell.org> #16244: Couldn't match kind ‘k1’ with ‘k1’ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program gives a hopelessly confusing error message on GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Kind type Const a b = a type SameKind (a :: k) (b :: k) = (() :: Constraint) class SameKind a b => C (k :: Const Type a) (b :: k) }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:18: error: • Couldn't match kind ‘k1’ with ‘k1’ • In the second argument of ‘SameKind’, namely ‘b’ In the class declaration for ‘C’ | 11 | class SameKind a b => C (k :: Const Type a) (b :: k) | ^ }}} I imagine that the real issue is that `SameKind a b` would force `a :: k`, which would be ill-scoped. But figuring that out from this strange error message requires a lot of thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 14:33:24 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 14:33:24 -0000 Subject: [GHC] #16245: GHC panic (No skolem info) with QuantifiedConstraints and strange scoping Message-ID: <050.e0d66715082b7391c2386e53a67a1579@haskell.org> #16245: GHC panic (No skolem info) with QuantifiedConstraints and strange scoping -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics with GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE QuantifiedConstraints #-} module Bug where import Data.Kind type Const a b = a type SameKind (a :: k) (b :: k) = (() :: Constraint) class (forall (b :: k). SameKind a b) => C (k :: Const Type a) }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:36: error:ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): No skolem info: [k1_a1X4[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors }}} As with #16244, I imagine that the real culprit is that `SameKind a b` would force `a :: k`, which would be ill-scoped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 14:59:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 14:59:38 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) Message-ID: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #15648 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Foo where import Language.Haskell.TH.Lib import Language.Haskell.TH.Syntax ueqT :: Q Type ueqT = conT $ mkNameG_tc "ghc-prim" "GHC.Prim" "~#" }}} {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Kind import Foo (ueqT) data JankyEquality :: Type -> Type -> Type where Jank :: $ueqT a b -> JankyEquality a b unJank :: JankyEquality a b -> $ueqT a b unJank (Jank x) = x }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs -dcore-lint GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In a case alternative: (Jank x_a4vR :: a_a4wC ~# b_a4wD) Non-CoVar has coercion type x_a4vR :: a_a4wC ~# b_a4wD *** Offending Program *** unJank :: forall a b. JankyEquality a b -> a ~# b [LclIdX] unJank = \ (@ a_a4wC) (@ b_a4wD) (ds_d4wN :: JankyEquality a_a4wC b_a4wD) -> case ds_d4wN of wild_00 { Jank x_a4vR -> break<0>() x_a4vR } }}} Note that this passes `-dcore-lint` on GHC 8.0.2 through 8.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 15:29:57 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 15:29:57 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.6b17205789789743c004a32c60e7d468@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simpler example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Foo (ueqT) f :: $ueqT a b -> $ueqT a b f x = x }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs -dcore-lint GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** Bug.hs:7:3: warning: [in body of lambda with binder x_a4vD :: a_a4vV ~# b_a4vW] Non-CoVar has coercion type x_a4vD :: a_a4vV ~# b_a4vW *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Bug"#) f :: forall a b. (a ~# b) -> a ~# b [LclIdX] f = \ (@ a_a4vV) (@ b_a4vW) (x_a4vD :: a_a4vV ~# b_a4vW) -> break<0>() x_a4vD end Rec } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 15:40:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 15:40:14 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.9cfc618070b681170dd0542e77c986ba@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hmm guess not, seems name mangling is wrong.. patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 15:42:10 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 15:42:10 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) In-Reply-To: <050.809cff7906dca54b71168422e3269d5a@haskell.org> References: <050.809cff7906dca54b71168422e3269d5a@haskell.org> Message-ID: <065.b8869d3a849249a61d930583146f9697@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16188, #16225 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 15:42:54 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 15:42:54 -0000 Subject: [GHC] #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) In-Reply-To: <050.51ee2352f2a4dae51e64e4bda9769d8b@haskell.org> References: <050.51ee2352f2a4dae51e64e4bda9769d8b@haskell.org> Message-ID: <065.05c93ac25b12947e7bd41387704b0ad7@haskell.org> #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16188, #16204 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 16:01:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 16:01:52 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.0de33eb3e225f045aa4fcdcbbe0c3e1e@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hrm. Maybe we should just drop that test? The problem is that GHC may look at a type and, if it's headed by `~#`, assume that any variable of that type is a coercion variable. There's nothing wrong in the theory if an ordinary variable has type `~#`... it's just perhaps an invariant that GHC might rely on (not sure). Another possibility is to have a check in `Convert` that prevents conversion of verboten things, like `~#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 16:25:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 16:25:02 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.82c9c56983808e7ad2273952f0b7016f@haskell.org> #16160: TH_NestedSplices fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/225 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/225 * milestone: => 8.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 16:25:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 16:25:50 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.b164209013f18fe482262472ffb59cee@haskell.org> #16160: TH_NestedSplices fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => new * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/225 => * milestone: 8.6.4 => Comment: whoops, wrong ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 16:26:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 16:26:29 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.e2345ea281775d823329ce4b6c3aa7ce@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/225 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/225 * milestone: => 8.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 18:43:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 18:43:52 -0000 Subject: [GHC] #16217: check-api-annotations should check that an annotation does not precede its span In-Reply-To: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> References: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> Message-ID: <059.8beb7c36fd167730bc121b57f4125e1d@haskell.org> #16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 19:54:47 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 19:54:47 -0000 Subject: [GHC] #16247: GHC 8.6 Core Lint regression (Kind application error) Message-ID: <050.86450994402b394920f8cc11311bffbb@haskell.org> #16247: GHC 8.6 Core Lint regression (Kind application error) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program produces a Core Lint error on GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data SameKind :: forall k. k -> k -> Type data Foo :: forall a k (b :: k). SameKind a b -> Type where MkFoo :: Foo sameKind }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of CorePrep *** : warning: In the type ‘forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind’ Kind application error in type ‘SameKind a_aWE b_aWG’ Function kind = forall k. k -> k -> * Arg kinds = [(k_aWF, *), (a_aWE, k_aWD), (b_aWG, k_aWF)] Fun: k_aWF (a_aWE, k_aWD) *** Offending Program *** MkFoo :: forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind }}} (Confusingly, the type of `MkFoo` is rendered as `forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind` in that `-dcore-lint` error, but I think it really should be `forall k1 (a :: k1) k2 (b :: k2) (sameKind :: SameKind a b). Foo sameKind`.) On GHC 8.4.4 and earlier, this simply produces an error message: {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:13: error: • These kind and type variables: a k (b :: k) are out of dependency order. Perhaps try this ordering: k (a :: k) (b :: k) • In the kind ‘forall a k (b :: k). SameKind a b -> Type’ | 9 | data Foo :: forall a k (b :: k). SameKind a b -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 21:18:30 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 21:18:30 -0000 Subject: [GHC] #3205: Generalized isomorphic deriving In-Reply-To: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> References: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> Message-ID: <057.af31cb2687ae217ebb2730bd085bc59d@haskell.org> #3205: Generalized isomorphic deriving -------------------------------------+------------------------------------- Reporter: ajd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: language, | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Isn't this feature request now implemented as `DerivingVia`? Perhaps we could close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 22:07:58 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 22:07:58 -0000 Subject: [GHC] #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. In-Reply-To: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> References: <047.7c61d3da68f06cf3150efc75527075f3@haskell.org> Message-ID: <062.53caa63362323ba737ece00c22f16e02@haskell.org> #16231: GHCi under powershell fails to find libgmp-10.dll when built with hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/237 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/237 Comment: I think that should fix it, but Hadrian dies locally for me. Will see when the CIs finish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 27 22:08:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Jan 2019 22:08:50 -0000 Subject: [GHC] #16160: TH_NestedSplices fails on Windows In-Reply-To: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> References: <046.ca753c52892a63d15306832189ecdb9d@haskell.org> Message-ID: <061.be69a43926fbf8f77d5db031bd1e3b78@haskell.org> #16160: TH_NestedSplices fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Where do you see these failures bgamari? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 00:06:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 00:06:35 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.f4756fb99d2cfcf98c89d8ce49422935@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Edit a comment in one file. > [...] > What happens though is that stage-1 is rebuilt Wait, this doesn't sound right. Which file did you edit? Here is what should have happened: the corresponding compiler should have been rerun generating the same object file, at which point the rebuild should have stopped (we call this feature "early cutoff"). Are we hitting GHC non- determinism here, i.e. the resulting object file was different after editing a comment? > Restore the LAX_DEPENDENCIES feature. I don't know the specification of that feature, but my experience is that it just did the Right Thing Although I agree that having a flag that does the Right Thing would be useful, I'd like to point out that Hadrian provides a general mechanism for skipping the rebuild of any collection of files. `--freeze1` simply uses this mechanism by skipping everything in `stage0//*`. Here is the corresponding code fragment: https://gitlab.haskell.org/ghc/ghc/blob/10faf44d97095b2f8516b6d449d266f6889dcd70/hadrian/src/Main.hs#L30-31 You can specify the files that should be ignored from the command line using `--skip` flag. For example, the equivalent of the flag `--freeze1` is `--skip=stage0//*`. > Somewhat separately, it might be nice to package up common idioms into smaller command lines. I think "build flavours" are the intended mechanism for common idioms, although typing `--flavour=...` is indeed inconvenient. We could add a shorthand `-f` for this. Separate scripts for such idioms sounds like a plausible approach too, although there is a risk that having multiple ways to do the same thing may be confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 03:01:57 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 03:01:57 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.a14bb05343050ca3762768a61e80f6a0@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 03:02:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 03:02:30 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.e3aa8d1d6d0b055cc1a6ab691d075bc3@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Looks like this is a proper GHC bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 07:35:13 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 07:35:13 -0000 Subject: [GHC] #16144: Provide integer-simple builds on Windows. In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.c6e82ed6daab0c473f297227fe1f6437@haskell.org> #16144: Provide integer-simple builds on Windows. -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pjljvdlaar): I don't like the change of this issue. I want to build my software using GHC on windows without getting a LGPL license. Currently, the libraries that cause this problem is indeed only integer- gmp. Choosing integer-simple instead of integer-gmp is indeed a valid solution. However, since any package that is linked could cause the same problem on windows, I prefer to keep the intention of this issue broad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 08:36:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 08:36:21 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.5519faa633874d26ef9aac31d3973320@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Just to address the second point here, the transformations that the renamer does for ApplicativeDo really are just annotations, not actual transformations, in the sense that you can easily get back the original program by just flattening out the `ApplicativeStmt`. It's done this way for exactly the reason you mentioned Simon - the typechecker needs to typecheck the code the user wrote. We also have to collect enough pieces that the desugarer can build the transformed Core expression, so the ApplicativeStmt has all the <$>, <*> and return identifiers. In the renamer there's an ad-hoc algorithm to group the `let` statements with the other statements in a `do`. I was never really happy with this, but it's important to do *something* otherwise `let` statements cause a loss of parallelism. We have tests for this - see `test9` in `testsuite/tests/ado/ado001.hs`. The paper doesn't deal with `let` unfortunately because we didn't include `let` statements in the grammar. It would be nice to fully understand and document what we do here. I also have a suspicion that we're not treating the last statement of the `do` in the way that the paper suggests - adding an extra `return` statement if the last statement is not a `return`. I think I was just lazy, because doing it in the way the paper suggests but without actually transforming the code (see discussion above) is a bit tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 08:59:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 08:59:21 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances Message-ID: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given: {{{#!hs {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE FlexibleInstances #-} module Test where data X a = X type XI = X Int class Foo a where foo :: (?p :: Int) => a -> Int instance Foo XI where foo = undefined }}} This code compiles. However, the documentation at https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #language-options says that ImplicitParams implies FlexibleInstances, so we should be able to remove the FlexibleInstances extension. However, doing so makes it stop compiling. My guess is that ImplicitParams doesn't really imply either of the type class extensions, and that the documentation is buggy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 09:22:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 09:22:31 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.1b650915dbf307f68520a4d3b0f59b09@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): `instance Foo XI ...` in the first case needs `TypeSynonymInstances`. That expands `XI` to `X Int`, then needs `FlexibleInstances`. `FlexibleInstances` is supposed to imply `TypeSynonymInstances`. I wonder if `ImplicitParams` switches on `FlexibleInstances` OK, but fails to also switch on `TypeSynonymInstances`? IOW try the code with `ImplicitParams` and `TypeSynonymInstances`, but not `FlexibleInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 09:29:26 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 09:29:26 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.8990ffe5ee0ce6dfe2edb36abb977495@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Comment (by simonpj): Hang on. It's possible that the patch for #16188 fixes this one too -- but the underlying cause of this ticket in `normaliseType` remains. Richard has an entirely separate (and sadly more substantial) patch for that, which he and I went through on Friday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 09:32:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 09:32:40 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.82cedb522bfcdccae87de47999a14dc9@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new Comment: Sorry! The description in https://gitlab.haskell.org/ghc/ghc/merge_requests/208 very strongly implies that it fixes this ticket, so I was just following suit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 09:46:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 09:46:14 -0000 Subject: [GHC] #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) In-Reply-To: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> References: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> Message-ID: <058.a68a09d8bf667a0194297175757bab1a@haskell.org> #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Ah, I see that I don't have orphan instances here, by the letter of the law: * `instance MyShow [a]` is declared in the same module as the class, so isn't an orphan; * `instance MyShow T` and `instance MyShow [T]` are declared in the same module as `data T`, so aren't orphans. Never the less, the problem is in the same ballpark as orphan instances: incoherence due to not all applicable instances being visible in all modules. Specifically, `instance MyShow [T]` is not visible in module `Help`, where constraint `MyShow [a] =>` on the signature for `showHelp` needs it. Then `OVERLAPPABLE` on `instance MyShow [a]` says 'beware! there are other instances in other scopes.' Is there a more accurate term or keyword I should use? ('orphan instance' seems to get bandied around on Stackoverflow in that more general sense.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 10:01:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 10:01:14 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.97d5d6447b3b1b5af26d4f63de36c655@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): To clarify the logic I'm using here: The above code requires TypeSynonymInstances, FlexibleInstances and ImplicitParams. To successfully compile, the minimum number of extensions I can write is ImplicitParams and FlexibleInstances. TypeSynonymInstances is not required. GHC claims that FlexibleInstances implies TypeSynonymInstances, and ImplicitParams implies FlexibleInstances. As a consequence FlexibleInstances should definitely be unnecessary. But it is required, so the docs are buggy. I had implicitly assumed that implications were transitive. Whether they are or not, the ImplicitParams still doesn't appear to imply FlexibleInstances. It would be good to document this detail in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 11:13:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 11:13:52 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.7672938b524b81e6e96f4753cd624cff@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In `docs/core-spec/core-spec.pdf`, the syntax of Core includes coercions and coercion variables ''c''. There is a different typing judgement for a coercion abstraction than for a non-coercion abstraction. The `CoVar` distinction in GHC is trying to track variables that range over coercions. One path might be to say that there is really no distinction (in Core anyway) between a `CoVar` and any other `Id`; but then why do we have two typing judgements? Another path might be to uphold the distinction, explain why we have it, and make sure it is respected. Richard, which would you suggest and why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 11:26:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 11:26:21 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.ef0688038df49fccfabb1e1eb5c2b88c@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Comment (by simonpj): Oh my bad. MR!208 is indeed the right one for this ticket. I was just mixed up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 11:28:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 11:28:06 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.2d759d4644280ac0218214d7df58dad1@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 11:57:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 11:57:08 -0000 Subject: [GHC] #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) In-Reply-To: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> References: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> Message-ID: <058.280c915b529de4d1fda9a1583f15e383@haskell.org> #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think only if the instance is not marked OVERLAPPABLE I'm not sure that's right. Currently [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #overlapping-instances the user manual for instance resolution] says this {{{ Eliminate any candidate IX for which there is another candidate IY such that both of the following hold: * IY is strictly more specific than IX. That is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable, or IY is overlapping. (This “either/or” design, rather than a “both/and” design, allow a client to deliberately override an instance from a library, without requiring a change to the library.) }}} The second bullet means that you don't need to say "OVERLAPPABLE" for an instance to be overlappable. It's enough to say "OVERLAPPING" in the overlapping instance. So you can't deduce anything much from the absence of "OVERLAPPABLE", sadly. I don't know if this is the right design. If we you could only overlap an explicitly-overlappable instance, we could commit to them more aggressively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 12:00:04 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 12:00:04 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.4b3539f52caccd3a9b9cbd32c64426d4@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looking at `main/DynFlags`, it doesn't look as if `ImplicitParams` implies anything. Why should it? Shall we just remove that claim from the user manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 12:01:50 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 12:01:50 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.e6d0736536860c8899f88cd064807c07@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Yep, removing the claim would be my suggestion. Happy to raise a PR, but I wonder how it got in there in the first place, and if there are any other mistakes that entered via the same route? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 12:08:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 12:08:21 -0000 Subject: [GHC] #16187: Hadrian: Build fails when using absolute path for build root In-Reply-To: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> References: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> Message-ID: <060.7fff0ab960cf28beb0f44880a1511487@haskell.org> #16187: Hadrian: Build fails when using absolute path for build root -------------------------------------+------------------------------------- Reporter: davide | Owner: sykloid Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian build Resolution: | root relative absolute path Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => sykloid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 12:35:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 12:35:58 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.3b08e5b6c64899fa643d4dcd9d429878@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15936 | Differential Rev(s): Phab:D3758, Wiki Page: | Phab:D5059 -------------------------------------+------------------------------------- Comment (by davide): I've been working on some changes recently, which is currently under review here [https://gitlab.haskell.org/ghc/ghc/merge_requests/22 !22]. To Summarize: * Gitlab CI pushes performance results to the [https://gitlab.haskell.org/ghc/ghc-performance-notes GHC Performance Notes] repo. * This is important for logging performance metrics. * When running performance tests, establish baseline (expected) performance values from older commits (not just the previous one) and even use performance numbers pushed from gitlab CI. * This should greatly improve usability: for many common workflows this will succeed in establishing a baseline where the previous method would fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 13:00:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 13:00:41 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.1ef054509877603286ca06efba06f69c@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T12509 Blocked By: | Blocking: Related Tickets: #13385, #14342 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/241 -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Gitlab Merge Request 23 => https://gitlab.haskell.org/ghc/ghc/merge_requests/241 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 13:13:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 13:13:22 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.6b4900f12aef36549cf55798e6442fc0@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): - Keeping `--html` but leaving out `--hyperlinked-source`: goes through. - Leaving out both `--html` and `--hyperlinked-source`: goes through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 13:34:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 13:34:58 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.e64219c7069f7ec1d200ec92255e00ba@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This users' guide entry was introduced in commit cf8ab1ced6f15dad03dd7bcc454ef759cf4d3b3d. Given that this was a very large refactoring of the way the users' guide was formatted, my guess is that this was simply an honest mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 14:16:37 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 14:16:37 -0000 Subject: [GHC] #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) In-Reply-To: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> References: <043.66db51b0ad6afd5f7add84127c8ad4ff@haskell.org> Message-ID: <058.91346b2ce9ab2952ded01858ce095418@haskell.org> #16241: Avoid orphan instances with OVERLAPPABLE (sometimes) -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Thanks Simon, > Currently the user manual ... is only talking about compiling within a single module, or at least when all instances are visible from imports in a single module. I.e. compiling module `Main` in the example. Or if you squish all the code into a single module then indeed > you don't need to say "OVERLAPPABLE" for an instance to be overlappable. But when compiling version 2 of module `Help` * there is only one visible instance of `MyShow` (so the quote from the manual doesn't apply: there's no alternative candidates to eliminate); * its head `[a]` does indeed match the wanted constraint `MyShow [a] =>` from the signature for `showHelp`, so it's the "prime candidate" per the user manual; and yet * the instance is marked `OVERLAPPABLE`, then GHC ''doesn't'' select that instance, contra what the user manual says. * I know it doesn't select that instance, because it doesn't simplify to constraint `MyShow a =>`. * Then in compiling module `Main`, we maintain referential transparency: `showHelp [MkT]` ===> `myshow [MkT]`, which wants `instance MyShow [T]` in preference to `instance MyShow [a]`. * So both calls in `main` produce the same result, viz `"Used more specific instance"`. So I'm disagreeing with your > It's enough to say "OVERLAPPING" in the overlapping instance. It is enough only providing those overlapping instance(s) are in the same module. If the overlapping instance(s) are in a separate module that's importing the `OVERLAPPABLE` instance, then you must say the imported instance is OVERLAPPABLE. > So you can't deduce anything much from the absence of "OVERLAPPABLE", sadly. Well, you can deduce you're liable to see "fragile"/"incoherent" behaviour ;-). > If we you could only overlap an explicitly-overlappable instance, we could commit to them more aggressively. I think you have that back-to-front: this ticket is showing currently GHC does commit aggressively to an eligible instance ''unless'' it's explicitly-overlappable. (And BTW per #15135, with `-O2` GHC commits aggressively anyway and ignores `OVERLAPPABLE`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 14:57:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 14:57:05 -0000 Subject: [GHC] #16232: Add setField to HasField In-Reply-To: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> References: <049.ab6bdf331dd86a9e320b4ce68b082aff@haskell.org> Message-ID: <064.5ace8016eff76f59c29f11c764013ff1@haskell.org> #16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: ORF, Resolution: | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: ORF => ORF, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 16:44:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 16:44:00 -0000 Subject: [GHC] #16249: no runtime error for -fdefer-type-errors with TypeError constraint Message-ID: <045.626de93e9953e5037e13e5097ffe4ce4@haskell.org> #16249: no runtime error for -fdefer-type-errors with TypeError constraint -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Part of a testsuite, I'm using `-fdefer-type-errors` to check if haskell expression raises type error. However the haskell expression may be perfectly valid except for a `TypeError` constraint on a typeclass. The following code: {{{#!haskell {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE DataKinds #-} import GHC.TypeLits class Foo t where foo :: t -> t foo = id instance Foo Int instance (TypeError (Text "String does not work")) => Foo String main :: IO () main = do putStrLn (show (foo 10 :: Int)) putStrLn (foo "hello") }}} Correctly generates errors when compiled: {{{ $ ghc ./DeferTypes.hs [1 of 1] Compiling Main ( DeferTypes.hs, DeferTypes.o ) [flags changed] DeferTypes.hs:17:13: error: • String does not work • In the first argument of ‘putStrLn’, namely ‘(foo "hello")’ In a stmt of a 'do' block: putStrLn (foo "hello") In the expression: do putStrLn (show (foo 10 :: Int)) putStrLn (foo "hello") | 17 | putStrLn (foo "hello") | }}} And also with `-fdefer-type-erros`, the error is transformed into a warning: {{{ $ ghc -fdefer-type-errors ./DeferTypes.hs [1 of 1] Compiling Main ( DeferTypes.hs, DeferTypes.o ) [flags changed] DeferTypes.hs:17:13: warning: [-Wdeferred-type-errors] • String does not work • In the first argument of ‘putStrLn’, namely ‘(foo "hello")’ In a stmt of a 'do' block: putStrLn (foo "hello") In the expression: do putStrLn (show (foo 10 :: Int)) putStrLn (foo "hello") | 17 | putStrLn (foo "hello") | ^^^^^^^^^^^ Linking DeferTypes ... }}} However, executing the program gives no runtime error: {{{ $ ./DeferTypes 10 hello }}} I was expecting something such as: {{{ $ ./DeferTypes 10 [a defered type error exception] }}} With ghc 8.6.3 from nix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 21:48:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 21:48:15 -0000 Subject: [GHC] #16250: Make it easy to invoke Hadrian Message-ID: <047.0f10265a465bb435804dd9916ec2e199@haskell.org> #16250: Make it easy to invoke Hadrian -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, invoking Hadrian requires running `hadrian/build.sh`. That's a small mouthful (when using it regularly), and it crucially depends on being in the root directory of GHC. It would be very convenient to have some command (say, `build`) which would work ''anywhere'' within the GHC tree, e.g. by searching for the root and then running the local Hadrian build script. Doing this would require devs to install something locally (so that it's in the PATH always), but that something can be small and light. Shall we fix? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 21:56:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 21:56:32 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.3e0ff0af8ef0dbe395760223c56c4e95@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: th/T16183 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/121 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => th/T16183 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 21:57:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 21:57:34 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.279cc176b38cb313cede2843e41ff1f4@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We need the distinction -- if ordinary `Id`s could represent coercions, then nothing is stopping us from having non-terminating coercions, which would kill the type system. (Note that we don't force `CoVar`s when casting by them, as they're computationally irrelevant.) But, there is nothing harmful (or useful, I think) about ordinary `Id`s that have coercion types. As these are not `CoVar`s, they cannot be used in casts (or anywhere else). But I don't see them causing any harm. So, all I'm really worried about is the possibility that someone, somewhere checks whether {{{tyConAppTyCon (idType id) `hasKey` eqPrimTyConKey}}} (or something) instead of checking `isCoVar id`. If we don't ever do that, then an `Id` with a coercion type is just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 21:57:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 21:57:40 -0000 Subject: [GHC] #16251: T5515 broken in devel2 flavour Message-ID: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> #16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `T5515` testcase is broken in the `devel2` build flavour: {{{ --- indexed-types/should_fail/T5515.run/T5515.stderr.normalised 2019-01-27 16:01:12.703091135 +0000 +++ indexed-types/should_fail/T5515.run/T5515.comp.stderr.normalised 2019-01-27 16:01:12.703091135 +0000 @@ -1,24 +1,12 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20190127 for x86_64-unknown-linux): + ASSERT failed! + rhs axiom D:R:Argf :: + Arg f = a_asO[sk:1] -- Defined at T5515.hs:15:8 + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/FamInst.hs:: in :FamInst -T5515.hs:6:16: - Expecting one more argument to ‘ctx’ - Expected a type, but ‘ctx’ has kind ‘* -> Constraint’ - In the first argument of ‘Arg’, namely ‘ctx’ - In the first argument of ‘ctx’, namely ‘(Arg ctx)’ - In the class declaration for ‘Bome’ - -T5515.hs:14:1: - Type variable ‘a’ is mentioned in the RHS, - but not bound on the LHS of the family instance - In the type instance declaration for ‘Arg’ - In the instance declaration for ‘Some f’ - -T5515.hs:14:10: - Could not deduce (C f a0) - from the context: C f a - bound by an instance declaration: - forall f a. C f a => Some f - at T5515.hs:14:10-24 - The type variable ‘a0’ is ambiguous - In the ambiguity check for an instance declaration - To defer the ambiguity check to use sites, enable AllowAmbiguousTypes - In the instance declaration for ‘Some f’ +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 22:21:53 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 22:21:53 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.dbacfd7b8122dd9be2d3f8c67febf1cb@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged with 08cfa6153171d7289e799b97940f51d322d8dd32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 22:25:49 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 22:25:49 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.715f201648933b5085f729ed1acb5f17@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I edited `Coercion.hs`. But, even if I had edited it in a meaningful way (instead of just editing a comment), I'm surprised to see the whole RTS rebuilt. I believe that's what `LAX_DEPENDENCIES` does for `make`: it assumes that, just because stage-1 has changed, it doesn't mean we need to rebuild everything that stage-1 built. Moreover, I really just wanted to run a test. So, I suppose I could do that with `build --skip=stage0//* --skip=stage1//* test --only=xyz`. Again, that's quite a mouthful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 22:53:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 22:53:52 -0000 Subject: [GHC] #16144: Provide integer-simple builds on Windows. In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.e0f6f61c8e8604d3c614f171a98b64ee@haskell.org> #16144: Provide integer-simple builds on Windows. -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): What you want is a different licensed integer library or a dynamically linked gmp and you take care of the distribution of said library. I changed the title because there's nothing "invalid" about the current license, and even for 7.x and 6.x releases gmp has been statically linked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 28 23:05:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Jan 2019 23:05:15 -0000 Subject: [GHC] #16144: Provide integer-simple builds on Windows. In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.4e1ec99281d85ed90b042b00c9f26f9e@haskell.org> #16144: Provide integer-simple builds on Windows. -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Feel free to change it to something specific and actionable, right now, the easiest way to get what you want is using integer-simple. If you want something else to be done that can also be taken into consideration. But the keywords and title before were just wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 00:19:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 00:19:02 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.212f4b67ce4a3ca676059eb4018a527f@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (LLVM) | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well this is mysterious. I have [[https://gitlab.haskell.org/JulianLeviston/ghc/-/jobs/18492|observed]] these tests unexpectedly passing on CI. Quite mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 01:53:24 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 01:53:24 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem Message-ID: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been debugging an issue that boils down to: quantified constraints are completely ignored during type inference. For example, in this program: {{{#!hs {-# language QuantifiedConstraints #-} module QC where data A f = A (f Int) eqA :: forall f. (forall x. Eq x => Eq (f x)) => A f -> A f -> Bool eqA (A a) (A b) = a == b eqA' :: (forall x. Eq x => Eq (f x)) => A f -> A f -> Bool eqA' = let g = eqA in g }}} `eqA'` won't compile because `g` gets generalised to `forall f. A f -> A f -> Bool`. I know this has been discussed (and dismissed) in tickets such as #2256 and #14942, but I really think it's a problem. In my example, I can get the code compiling by turning on ScopedTypeVariables and giving `g` an annotation. But I don't always have this liberty. For example, in the `deriving-compat` library there's Template Haskell that generates definitions containing `let`s, and when a quantified constraint is present these splices don't type check for the same reason `eqA'` doesn't. The solution here involves a pull request to `deriving-compat` that uses ScopedTypeVariables to annotate the problematic `let`s. But I really think that none of this should be necessary. The reference implementation of QCs (https://github.com/gkaracha/quantcs-impl) doesn't seem to have this problem. Is there anything I'm missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 03:30:33 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 03:30:33 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.5dfb1a2270034fb8362eef91cec3518d@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): It looks like the problem is GHC is incorrectly attempting to build the object file for the indefinite package. Working versus non-working (working version by commenting out TemplateHaskell) {{{ -[2 of 2] Compiling C ( library-b/C.hs, nothing ) +Read the interface file dist/build/library-b/C.hi +[2 of 2] Compiling C ( library-b/C.hs, /tmp/ghc11640_0/ghc_1.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 03:35:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 03:35:49 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.83c2afe21de043a3c32ee0f0dcebb2ac@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): From code reading, it looks like this is a bad interaction between indefinite packages, and our special logic to handle `-fno-code` builds that use TemplateHaskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 04:22:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 04:22:59 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.2fdcc728e0c61659b22b15e9592ca067@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D5475 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 04:53:57 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 04:53:57 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.85e878fd61d41127487a942e06b27576@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): Your phabricator comment says: > It should work to write an indefinite package using TemplateHaskell, so long as all of the actual TH code lives outside of the package. Will this always be the case? No TH in indefinite packages? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 09:17:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 09:17:53 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.517e805642ea0d09a3787dcba0b192c5@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting! I can see what is happening. Given a binding `g = rhs`, GHC infers all the constraints C from `rhs` and tries to generalise. Currently that works as follows (`simplifyInfer`) 1. `approximateWC`: find `quant_pred_candidates`, the subset of constraints in C over which we could conceivably quantify. 2. Pick a set of `quant_pred_candidates` to quantify over 3. Crucially, do not generalise over any type variable free in a constraint we decide not to generalise in Step 2. (If we generalise over that type variable, the constraint will probably become insoluble.) The problem is that we don't account for constraints (such as implication constraints) that Step 1 discards! We do generalise over their type variables, and they duly become insoluble. That's why your definition of `g` is being generalised. Solution: don't generalise over any type variable free in a constraint that we can't quantify. I'm quite surprised this has not come up before. The fix will be a big fiddly but not really hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 09:32:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 09:32:49 -0000 Subject: [GHC] #16222: PPC NCG: C calling convention violated for integers smaller than word size In-Reply-To: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> References: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> Message-ID: <062.d2f51a2b5b022c360f646b62ca7d6bc8@haskell.org> #16222: PPC NCG: C calling convention violated for integers smaller than word size -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (FFI) | Version: 8.7 Resolution: | Keywords: big endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/PrimFFIInt8 | primops/should_run/PrimFFIInt16 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/220 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/220 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 10:25:07 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 10:25:07 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` Message-ID: <044.233cab30828031655fa37ffd46491b99@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When working on a stage1 compiler, the slightest change in any of the files leads to rebuilding the dependency matrix, which takes 20-30s time. That makes for a very disruptive edit-compile cycle. Alp helped me on #ghc and found `--skip=_build/stage0/compiler/.dependencies.mk` as the right flag to skip dependency rebuilding. I wonder if could hide that behind a nicer flag? I think this should do similar things as `--freeze1`, only that we 'freeze' stage 0 and dependency building. The analogy is that we need a hadrian equivalent of `make -C ghc 1` as we have `--freeze1` for `make -C ghc 2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 10:32:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 10:32:41 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.7602648ff89b701471099c47a9e53753@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: goldfire (added) Comment: Let me also add @goldfire here who was asking similar questions in this ticket: https://ghc.haskell.org/trac/ghc/ticket/16242 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 10:34:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 10:34:12 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.720bf6ee093f3b293911b9f060e32b4d@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 10:36:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 10:36:30 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.8dd74a29a2d997fd9502d0d7315e16f1@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > When working on a stage1 compiler, the slightest change in any of the files leads to rebuilding the dependency matrix, which takes 20-30s time. That makes for a very disruptive edit-compile cycle. This is mysterious to me. I thought that part of the wonderfulness of Shake and early cut-off was that all this repeated work is not done. So why is that not working? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 10:45:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 10:45:01 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.9348c3eca7cdb3e9e8c8cc04d0825717@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Simon: this is expected behaviour in this case. Dependency analysis of Haskell sources is performed on per package (not per file) basis, in one go. Whenever a single source file is changed, we invoke `ghc -M` on the whole package, which can take a while for a large package. This is how Make works too, but it often disables the tracking mechanism, which may lead to incorrect build results but is fast. Perhaps, we could/should switch to dependency analysis on the per-file basis (as we do with C sources), which would directly address this particular ticket without introducing yet another way to disable tracking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 11:23:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 11:23:18 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.db7e85fdd6f8d92ec7c56a8f1ab06b9b@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Looking at the documentation of `ghc -M`, it looks like the current per- package approach is due to a limitation of GHC's dependency analysis. Quoting from https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html #makefile-dependencies > In general, `ghc -M Foo` does the following. For each module `M` in the set `Foo` plus all its imports (transitively), it adds to the Makefile [...] That is, GHC always does **transitive** dependency analysis, which means invoking it separately on each file would be rather inefficient (each time it will likely traverse almost the whole dependency graph). This is why Make and Hadrian choose to perform the analysis just once but for the whole package. Perhaps, it's not too difficult to add a more fine-grain dependency analysis to GHC, i.e. produce only the list of immediate dependencies of a specified module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 11:26:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 11:26:40 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.6a5c28b0043e22f1685c976a442a65f1@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Perhaps, it's not too difficult to add a more fine-grain dependency analysis to GHC, i.e. produce only the list of immediate dependencies of a specified module. I'm sure it would be hard to have another flag so that `ghc -new-flag M.hs` would produce just the immediate dependencies of `M`. Would that solve the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 11:49:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 11:49:49 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.b6c315ffcd6593cc1ac629c52d74fe4e@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Would that solve the problem? Yes, switching to per-file dependencies in Hadrian would be easy if we had such flag. However, per-package vs per-file is a bit of a trade-off. Per-package analysis will likely be faster for the full build (you do analysis only once instead of for each file separately), whereas per-file analysis will be faster for incremental builds. (It is likely that the reduction of performance for the full build when switching to the per-file approach will be negligible, but we'll need to check this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 12:09:14 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 12:09:14 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.06f3273076baab34b08595ab86c7e05f@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: NeilMitchell (added) Comment: Speaking of the trade-off, perhaps, this is a nice use case for Shake's "batching" feature: http://hackage.haskell.org/package/shake-0.17.4/docs/Development- Shake.html#v:batch We could have a batching rule for dependency analysis: if multiple files need to be analysed, their analysis could be combined into a single GHC invocation. That would be quite cool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 12:15:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 12:15:15 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.4526ff7e93255099e08f948f92c3cc25@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Yes, switching to per-file dependencies in Hadrian would be easy if we had such flag. OK, let's do it! Can't be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 12:36:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 12:36:50 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.557f201872adfb87a0eef2561aea2df6@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Andrey, is the reason this is hideously expensive because {{{ghc -M}}} is hideously expensive? If not, then using oracles to cache the various parts of {{{dependencies.mk}}} would be the right solution. I believe the way {{{-M}}} works is it builds a complete dependency tree, which is pretty expensive, and requires running all C preprocessors etc. Doing it in individual steps is likely to be hideously expensive. The solution I've always used in the past is something like https://shakebuild.com/includes#generated-transitive-imports. Pro's are it's super fast, super granular and allows you to import files that are themselves generated on demand. Con is that you have to write your own "spot an import" code. My experience is that's really hard ''in general'' but quite easy for any specific project with sane conventions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 12:52:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 12:52:44 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.620fbeaad86918b7b187f38a65b3c4ff@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you describe more explicitly "the solution you have used in the past" in our context? I think you are saying * Implement `ghc -scome-new-flag M.hs` which runs CPP on `M.hs` (if necessary), parses the result in some simple minded way, and spits out all of `M`'s direct imports. This seems to be what your `usedHeaders` thing does. If we could do `need (usedHeaders "M.hs")` maybe we would never need to use `ghc -M` at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 12:59:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 12:59:11 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.3abcea13e3fe5f2165f33a60949fe7d1@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): In the past I've written a function that reads the file, and using fairly simplistic string matching guesses what it depends on, in the build system itself. It can avoid shelling out to GHC (hugely expensive on Windows, especially with corporate antivirus systems) and avoid running CPP. Generally most CPP doesn't impact which files are used, and even if it does, having a superset isn't a problem. The kind of function I've used previously is on the order of: {{{#!hs [... extract_the_module_name x ... | x <- lines src, "import " `isPrefixOf` x] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 13:00:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 13:00:50 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.97e2db8450a5188e91b37205c044c6cb@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Andrey, is the reason this is hideously expensive because `ghc -M` is hideously expensive? There are ~500 Haskell files in the `compiler` directory, so global (i.e. per-package) dependency analysis can't be very fast, however efficiently it is implemented. > If not, then using oracles to cache the various parts of `dependencies.mk` would be the right solution. This is what we do, but this doesn't solve the problem: right now, if you edit a single Haskell file in `compiler`, we will rerun `ghc -M` on the whole set of ~500 package files. Yes, oracles will helpfully cut the changes from propagating further, but this single `ghc -M` invocation will be slow. I think the only solution is to have a way (e.g. a new GHC flag) to run dependency analysis on a single file, without transitive exploration of all its dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 13:02:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 13:02:12 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.745dc867ef3b6ee0696e67ae0bfc43d1@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Neil: Doing conservative dependency analysis directly from within Hadrian is an option too! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 13:04:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 13:04:16 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.919c04b991e54203be15ad98e67edb6d@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): > I think the only solution is to have a way (e.g. a new GHC flag) to run dependency analysis on a single file, without transitive exploration of all its dependencies. That sounds reasonable. It would certainly be more robust than the strategy I describe. It won't help if you have deeply nested CPP includes (you'd still rescan them each time), but I suspect that's negligible for GHC. As you say, if that flag can take multiple files at once, you could batch it, which would be a good performance improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 15:04:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 15:04:50 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining Message-ID: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5327 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #5327, we allowed case-of-known constructor to see through bindings that were marked as INLINABLE and used newtypes. However, this works only if the newtype does not have a wrapper. The following code, which is the same as T5237 except for the extra type parameters in Size, does not cause the optimization to fire. {{{ {-# LANGUAGE GADTs, ExplicitForAll #-} module T16254 where newtype Size a b where Size :: forall b a. Int -> Size a b {-# INLINABLE val2 #-} val2 = Size 17 f n = case val2 of Size s -> s + s > n }}} The reason is that `exprIsConApp_maybe` sees `$WSize (I# 17#)`, which is an application with a nontrivial argument. In general, this could cause duplication of work, but in this case we're dealing with a newtype wrapper, so this is safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 15:05:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 15:05:23 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.b828d590ee0aa40f8a8e6753739343c9@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: (none) => monoidal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 16:00:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 16:00:50 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind Message-ID: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: #15740 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After #15740, GHC now (correctly) rejects this program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind data SBool :: Bool -> Type type family F :: forall k. k -> Type where F = SBool }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:7: error: • Expected kind ‘forall k. k -> *’, but ‘SBool’ has kind ‘Bool -> *’ • In the type ‘SBool’ In the type family declaration for ‘F’ | 12 | F = SBool | ^^^^^ }}} However, there's a very simple way to circumvent this: add a visible kind application to `F`'s equation. {{{#!hs type family F :: forall k. k -> Type where F @Bool = SBool }}} If I understand things correctly, GHC shouldn't allow this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 16:13:38 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 16:13:38 -0000 Subject: [GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries In-Reply-To: <048.4844eff8eedd12903d2ac77488728672@haskell.org> References: <048.4844eff8eedd12903d2ac77488728672@haskell.org> Message-ID: <063.898805a6d919ac6769cc4c7e4606678a@haskell.org> #16228: ghc-pkg and ghc do not agree about package with internal libraries ---------------------------------+-------------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 16:50:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 16:50:26 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.363050d958802ce898082e75a0b2bb19@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Changes (by monoidal): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 16:50:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 16:50:37 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.83c132b74efa6411307bb1e8a73a04b8@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 16:53:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 16:53:50 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.5f974fe68a5b30df00799b2e8ef273dd@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You understand things correctly. The arity checker probably only looks at the visible arity, which is correct, and the kind, which is also correct. Of course, that's clearly not the whole story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 17:03:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 17:03:37 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.0215e6016e3eac8fa8bf6b10744f3f8c@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Comment (by simonpj): > The reason is that exprIsConApp_maybe sees $WSize (I# 17#) This is true only if data constructor wrappers are inlined late, isn't it? Or is it some true even of (say) GHC 8.6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 17:09:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 17:09:27 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.38ae09d541c305f4d54471e2c6360312@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Comment (by monoidal): The is true in GHC 8.6 or master - it doesn't require the inlining late patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 17:14:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 17:14:26 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.2437dee28a416c49262c80688893e5b6@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I can give a shot at implementing this `-M`-on-a-diet flag idea, so as to then use this when appropriate in Hadrian, whenever this would save us work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 17:50:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 17:50:01 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.0ae552cb8ab70c8b1b01a31f725a20e0@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. I wonder why? I'd expect Size's wrapper to be inlined even inside the INLINEABLE unfolding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 18:25:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 18:25:17 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.f8362f9f91cbb39f71bced2873428d07@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/225 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => merge Comment: Thanks for the report `crockeea` and the reproducer `RyanGlScott`. If you require, you can work around this by making a file {{{ PROVIDE(__chkstk_ms = ___chkstk_ms); }}} called `workaround.ldscript` and tell GHC `-optl"workaround.ldscript"` or add that as `ghc-options` in your cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 18:57:58 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 18:57:58 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.da8e8a86874a3a74e8645f4f580ebe3f@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Your hunch is correct, since [https://gitlab.haskell.org/ghc/ghc/blob/7cdcd3e12a5c3a337e36fa80c64bd72e5ef79b24/compiler/typecheck/TcTyClsDecls.hs#L1736-1739 the current implementation] of the arity checker ignores invisible arguments entirely: {{{#!hs -- this check reports an arity error instead of a kind error; easier for user ; let vis_pats = numVisibleArgs hs_pats ; checkTc (vis_pats == vis_arity) $ wrongNumberOfParmsErr vis_arity ... where vis_arity = length (tyConVisibleTyVars tc_fam_tc) }}} I wonder if fixing this check is as simple as adding another `checkTc` for the number of specified arguments? Something like: {{{#!hs ; let invis_pats = length hs_pats - vis_pats ; checkTc (invis_pats <= specified_arity) $ error "You done goofed" ... where specified_arity = length [ tv | Bndr tv vis <- tyConBinders tc , tyConBndrVisArgFlag vis == Specified ] }}} I can only think of one place where this sort of thing could go wrong. If you instantiate a specified argument with `forall a. a`, then you could theoretically do something like this: {{{#!hs type family F :: k where -- One specified binder... F @(forall a. a) @Bool = True -- ...but two specified arguments! }}} That being said, GHC currently doesn't allow type family definitions like this one: {{{ • Illegal polymorphic type: forall a. a • In the equations for closed type family ‘F’ In the type family declaration for ‘F’ }}} So perhaps this isn't an issue in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 19:13:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 19:13:21 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.18d8208f296cd107c3d652a08c42f9e8@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, hypothetically, it might be possible to get TH for modules which don't transitively depend on a signature in the indefinite package. But, fundamentally, there's no way to have TH which depends on a signature, since the TH splice affects type checking, but you have no idea what the actual implementation of the splice is! You can always work around these problems by making more packages. Maybe if you say more about your use case I might be able to better advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 19:32:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 19:32:45 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.a7f4d55d09012d37eca6cbfc6ce15685@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/248 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/248 Comment: I was able to replicate (and fix) this. The issue manifests as a hang, very slowly running out of memory, on OSX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 19:54:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 19:54:39 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.3ff6effeb3e5ec546ddf829f87cbe1c6@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have no idea what that `F` would mean if it were allowed. Thankfully, it's not. I don't think it's as simple as that arity check, though. Witness {{{#!hs type family F (x :: j) :: forall k. Either j k where F 5 @Symbol = Left 4 }}} That looks well-kinded to me, it has the right visible arity, and it has the right specified arity, but it's still wrong. To get this right, I think we have to look not at the overall specified arity, but the specified arity ''after the last visible argument''. If we get that right, I think we've gotten this aspect right. (Note that a problem before the last visible argument must necessarily be a kind error, not an arity error.) That's a bit gross, but I think it will work. This should probably be done in the validity checker. The spot you've edited above is in the kind-checker. The only reason the visible arity check is done there is because it gives a nicer error message. These checks morally ought to be later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 20:26:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 20:26:23 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.4a460b844c0ffceabe94d73a8e3421b0@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Self-note: the relevant code lives in https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/main/DriverMkDepend.hs. The simplest approach is probably to refine that `GhcMode` to be either transitive or not. When transitive, we'd take the current code path, when not, we'd take the new one that just looks at and reports the immediate dependencies. The former would still be exposed under `-M` and the new one under some other flag (any suggestion is welcome). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 22:31:42 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 22:31:42 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.6d865cadffc99122f9de7c525c626276@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 goldfire]: > This should probably be done in the validity checker. How would that possibly work? By the time we're in the validity checker, all we have are `CoAxBranch`es, which don't distinguish between required and specified arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 22:45:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 22:45:46 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.e8e01f6af843657b02c8796ea316b784@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): What does it mean to 'quantify over a constraint' here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 22:47:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 22:47:01 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.0ff1263385967acf1487e594d8a5a02d@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I just realized the answer to my own question: this information is (indirectly) stored in the `tyConBinders` of the type family tycon. We'd have to do a little bit of reverse engineering to recover which type patterns had which visibility, but it should be possible (I think). Another challenge is figuring out a good `SrcSpan` to use in the error message, which we don't have any location info in `TcValidity`. Maybe we'll just have to settle for the `SrcSpan` of the entire type family equation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 29 23:15:14 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Jan 2019 23:15:14 -0000 Subject: [GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` In-Reply-To: <044.233cab30828031655fa37ffd46491b99@haskell.org> References: <044.233cab30828031655fa37ffd46491b99@haskell.org> Message-ID: <059.da052229c492858ae6073e130363e64d@haskell.org> #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks taking this up, Alp! We could name the new flag `-M1` -- this would suggest that only dependencies at "depth" 1 are reported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 00:53:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 00:53:38 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.225b9139c7d8469ccf5d4b22068fb73d@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (LLVM) | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I tried running a test locally where I only observed the following failures: {{{ =====> TH_repPrim(ext-interp) 3 of 11 [0, 2, 0] cd "th/TH_repPrim.run" && "/mnt/work/ghc/ghc/inplace/bin/ghc-stage2" -c TH_repPrim.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -XTemplateHaskell -package template-haskell -fexternal- interpreter -v0 Compile failed (exit code 1) errors were: AppE (ConE GHC.Types.I#) (LitE (IntPrimL 20)) GHC.Types.I# 20# AppE (ConE GHC.Types.W#) (LitE (WordPrimL 32)) GHC.Types.W# 32## TH_repPrim.hs:23:29: error: • Exception when trying to run compile-time code: ghc-stage2: ghc-iserv terminated (-11) Code: do e <- [| F# 12.3# |] runIO $ putStrLn $ show e runIO $ putStrLn $ pprint e .... • In the untyped splice: $(do e <- [| F# 12.3# |] runIO $ putStrLn $ show e runIO $ putStrLn $ pprint e runIO $ hFlush stdout ....) *** unexpected failure for TH_repPrim(ext-interp) =====> TH_repPrim2(ext-interp) 4 of 11 [0, 3, 0] cd "th/TH_repPrim2.run" && "/mnt/work/ghc/ghc/inplace/bin/ghc-stage2" -c TH_repPrim2.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -XTemplateHaskell -package template-haskell -fexternal- interpreter -v0 Compile failed (exit code 1) errors were: LitE (IntPrimL 20) 20# LitE (WordPrimL 32) 32## TH_repPrim2.hs:23:29: error: • Exception when trying to run compile-time code: ghc-stage2: ghc-iserv terminated (-11) Code: do e <- [| 12.3# |] runIO $ putStrLn $ show e runIO $ putStrLn $ pprint e .... • In the untyped splice: $(do e <- [| 12.3# |] runIO $ putStrLn $ show e runIO $ putStrLn $ pprint e runIO $ hFlush stdout ....) *** unexpected failure for TH_repPrim2(ext-interp) =====> T11721_TH(ext-interp) 5 of 11 [0, 4, 0] cd "th/T11721_TH.run" && "/mnt/work/ghc/ghc/inplace/bin/ghc-stage2" -c T11721_TH.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -XTemplateHaskell -package template-haskell -fexternal- interpreter -v0 Compile failed (exit code 1) errors were: T11721_TH.hs:15:3: error: • Exception when trying to run compile-time code: ghc-stage2: ghc-iserv terminated (-11) Code: do let rightOrder :: [TyVarBndr] -> Bool .... TyConI (DataD _ _ _ _ [ForallC con_tvbs1 _ _] _) <- reify ''T DataConI _ (ForallT con_tvbs2 _ _) _ <- reify 'MkT .... • In the untyped splice: $(do let rightOrder :: [TyVarBndr] -> Bool rightOrder [KindedTV b _, KindedTV a _] = nameBase b == "b" && nameBase a == "a" rightOrder _ = False TyConI (DataD _ _ _ _ [ForallC con_tvbs1 _ _] _) <- reify ''T DataConI _ (ForallT con_tvbs2 _ _) _ <- reify 'MkT if rightOrder con_tvbs1 && rightOrder con_tvbs2 then [| () |] else fail "T11721_TH failed") *** unexpected failure for T11721_TH(ext-interp) =====> T15502(ext-interp) 6 of 11 [0, 6, 0] cd "th/T15502.run" && "/mnt/work/ghc/ghc/inplace/bin/ghc-stage2" -c T15502.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 -ddump-splices -dsuppress-uniques Compile failed (exit code 1) errors were: T15502.hs:7:16: error: • Exception when trying to run compile-time code: {handle: }: GHCi.Message.remoteCall: end of file Code: lift (toInteger (maxBound :: Int) + 1) • In the untyped splice: $(lift (toInteger (maxBound :: Int) + 1)) *** unexpected failure for T15502(ext-interp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 01:09:53 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 01:09:53 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.20e42b21bcd1ae737d3e830633014fc9@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (LLVM) | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm going to look a bit harder at `T15502`. The test is quite simple: {{{#!hs main = print ( $( lift (toInteger (maxBound :: Int) + 1) ) , $( lift (minBound :: Int) ) ) }}} GHC falls over when evaluating the first splice. If I comment it out compilation finishes without crashing. Consequently, the minimal reproducer is: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax (Lift(lift)) main = print $( lift (toInteger (maxBound :: Int) + 1) ) }}} compiled with `-fexternal-interpreter` by a GHC compiled with `-fllvm`. Indeed, this is also easily reproducible with `ghci`: {{{ inplace/bin/ghc-stage2 -fexternal-interpreter --interactive GHCi, version 8.7.20190128: https://www.haskell.org/ghc/ :? for help Prelude> print $ toInteger (maxBound :: Int) + 1 ghc-stage2: ghc-iserv terminated (-11) Leaving GHCi. }}} The backtrace after the crash reliably looks like: {{{ >>> x/80a $rbp 0x4200185e48: 0x8000000000000000 0x1b59860 0x4200185e58: 0x420001fad8 0x41de6980 0x4200185e68: 0x420001fad8 0x41677621 0x4200185e78: 0x40c63dd8 0x420001fad8 0x4200185e88: 0x41068ca1 0x40c64290 0x4200185e98: 0x1b59860 0x4200033518 0x4200185ea8: 0x40b5c330 0x4165e490 0x4200185eb8: 0x4200033518 0x40b6f020 0x4200185ec8: 0x4165e490 0x4200033518 0x4200185ed8: 0x41068c7a 0x40a02560 0x4200185ee8: 0x420001fa80 0x1b59040 0x4200185ef8: 0x1b59490 0xc 0x4200185f08: 0x42000334aa 0x40cb3790 0x4200185f18: 0x420002e879 0x4200032512 0x4200185f28: 0x420002b7d0 0x420003301a 0x4200185f38: 0x1b59490 0xc 0x4200185f48: 0x4200032002 0x40cb3790 0x4200185f58: 0x420002e879 0x4200030082 0x4200185f68: 0x420001fa18 0x4200031122 0x4200185f78: 0x1b58f00 0xf38490 0x4200185f88: 0x1b59490 0x0 0x4200185f98: 0x420002e7ca 0xf38570 0x4200185fa8: 0x1b59490 0x0 0x4200185fb8: 0x1e02eca 0xf386c8 0x4200185fc8: 0x1b59070 0xf388d0 0x4200185fd8: 0x420002e580 0x1b59490 0x4200185fe8: 0x4 0x1eaec12 0x4200185ff8: 0x1b5cad0 0x1b56b30 0x4200186008: 0x8000 0x10000000113 0x4200186018: 0x23000000000000 0x2000000000000000 0x4200186028: 0x4 0x4200186158 0x4200186038: 0x41068ca0 0x4163b8b8 0x4200186048: 0x420002f100 0x1b13e20 0x4200186058: 0x8000 0x1b13e70 0x4200186068: 0x4200186189 0x1fd7e11 0x4200186078: 0xe51ac8 0x42001861b5 0x4200186088: 0x11953a0 0x1def943 0x4200186098: 0x1def909 0x1def8fa 0x42001860a8: 0x119c158 0x42001852e9 0x42001860b8: 0x1195080 0x1b13e70 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 01:51:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 01:51:47 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.715fe138bff374073f50488226e8fcda@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): My use case is that I have a large datatype, where some of the fields are datatypes that contain abstract datatypes (these abstract datatypes are declared in a signature in another package). I want to use TH to generate lenses for the large indefinite datatype. Also, should we take this particular discussion off the tracker? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 02:10:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 02:10:21 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.f2cc31a8f0b8b3f7255ce385cf37c747@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: | JulianLeviston Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): This is my plan so far: - add `DynLinker` `newtype` and use feed it into all the functions where we used to use the `v_PersistentLinkerState` global `IORef` state - rewrite `modifyPLS` and `modifyPLS_` to work with the passed-in `DynLinker` `IORef` value rather than the global - survey all the places where we've added `DynLinker` as an argument (in 1st *or* 2nd pos) extendLoadedPkgs - extendLinkEnv - deleteFromLinkEnv - getHValue - withExtendedLinkEnv - initDynLinker - reallyInitDynLinker - linkCmdLineLibs - linkExpr - linkDecls - linkModule - unload - linkPackages - - refactor all the surveyed call sites such that they're also passing now the DynLinker argument - rewrite initDynLinker as per wiki - rewrite withLinkerState as per wiki (this is just old modifyPLS, basically...) - rewrite readPLS to be passed DynLinker and refactor its sole call-site - rewrite modifyMbPLS_ so it works with DynLinker - try compiling and fix any errors - write a test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 07:39:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 07:39:11 -0000 Subject: [GHC] #16144: Provide integer-simple builds on Windows. In-Reply-To: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> References: <049.6d4c283280bfa86bc9951d3f31f6c49d@haskell.org> Message-ID: <064.fccaad60ec45faba268e2b11fa232960@haskell.org> #16144: Provide integer-simple builds on Windows. -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pjljvdlaar): See e.g. https://stackoverflow.com/questions/140061/when-to-use-dynamic- vs-static-libraries if you are using LGPL licensed code and you link statically against a LGPL library (and thus create one big binary), your code automatically becomes Open Sourced (free as in freedom) LGPL code. Hence, since GHC on windows statically links its libraries with my source code: all my source code is LGPL code when I want to support the windows platform. For most organizations, a LGPL license is NOT acceptable. So maybe the title should have been ensuring acceptable license of software developed with GHC on all platforms. And indeed, for now releasing an integer-simple ghc version does the trick, but I think GHC should address the general problem to become acceptable/ increase usage on the windows platform! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 12:52:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 12:52:02 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.12e531ce9dce2269cb6679d46780e9b2@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/247 -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 13:00:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 13:00:20 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.2a61a7692fccba20aa61b3d98c6eb8a2@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): It was merged into master via https://gitlab.haskell.org/ghc/ghc/merge_requests/244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 13:25:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 13:25:20 -0000 Subject: [GHC] #16208: map/coerce does not fire with all newtypes In-Reply-To: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> References: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> Message-ID: <062.ca0691b1dfa33b0017ea8793488e640d@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Kryztoph, let me know if you need help diagnosing this. Or maybe you already know what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 14:06:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 14:06:20 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.2a690f734a0444ba4db005e6eec41a0c@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by josef): simonpj, I don't agree with how you characterized my comments. You wrote: > Second, for the program in comment:5, as josef points out in comment:11, the renamer rewrites the program to a form that really would > require full-on impredicative polymorphism to propagate f's polymorphism. I must have explained myself very poorly. The point I was trying to get across is that we **don't** need full-on impredicative polymorphism. Instead, I believe we can solve the problem for ApplicativeDo by simply changing the algorithm that ApplicativeDo uses to handle `let` statements, just as simonmar suggested. In fact, I think that this ticket should be split up so that we have a separate ticket for ApplicativeDo. The remedies for parallell monad comprehension and ApplicativeDo seem very different. I'll create a new ticket for ApplicativeDo unless someone yells. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 15:31:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 15:31:30 -0000 Subject: [GHC] #16256: -fexternal-interpreter slow for profiling with template haskell Message-ID: <045.91f10a928f9d3a1420230057242969f8@haskell.org> #16256: -fexternal-interpreter slow for profiling with template haskell -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to build the following program (in `Foo.hs`) with profiling enabled: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} main = print $([| 10 |]) }}} With the "alternate object file suffix" method, I have correct build time: {{{ $ time ghc -prof -osuf o_p Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o_p ) Linking Foo ... real 0m1.698s user 0m1.518s sys 0m0.184s }}} However with `-fexternal-interpreter`, times are abysmally slow: {{{ $ time ghc -prof -fexternal-interpreter -osuf "p_o" Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.p_o ) Linking Foo ... real 0m26.077s user 0m1.531s sys 0m0.190s }}} I'm using `ghc-8.6.3` on nixos. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 16:00:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 16:00:02 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase Message-ID: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm building the following `Foo.hs` program using the `hmatrix-gsl` library: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} import Numeric.GSL.Integration main = do print $([| 10 |]) print $ integrateQNG 1 (\x -> x) 0 1 }}} I observes undefined symbols during the template haskell phase when using `-fexternal-interpreter`: Without `-fexternal-interpreter`: {{{ $ ghc -package hmatrix-gsl Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... [nix-shell:~/bug_report_external]$ ./Foo 10 (0.5,5.551115123125783e-15) }}} But with `-fexternal-interpreter`: {{{ $ ghc -fexternal-interpreter -package hmatrix-gsl Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) : can't load .so/.DLL for: /nix/store /6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgsl.so (/nix/store /6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgsl.so: undefined symbol: cblas_ctrmv) }}} I suspect that it happen during the template haskell phase because I cannot observe this issue without template haskell. I can observe this issue with a few other libraries, I used `hmatrix-gsl` in this example because it is on hackage. Actually, you can even reduce the file to: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} main = do print $([| 10 |]) }}} and get the same error as long as you have `-package hmatrix-gsl` in your command line. I generate the build environment with this nix file: {{{#!nix with import (fetchTarball { # 25/01/2019 url = https://github.com/nixos/nixpkgs/archive/11cf7d6e1ff.tar.gz; sha256 = "0zcg4mgfdk3ryiqj1j5iv5bljjvsgi6q6j9z1vkq383c4g4clc72"; }) {}; mkShell { buildInputs = [(haskellPackages.ghcWithPackages(p: [p.hmatrix-gsl]))]; } }}} It setups `ghc-8.6.3` with `hmatrix-gsl-0.19.0.1` (the latest on hackage). Note that `hmatrix-gsl` depends on library `gsl` which have a weird symbol setup. The main library file `libgsl` does not contain the `cbal_ctrmv` symbol which is contained in another library `libgslcbal` which is not a dependency of the shared object `libgsl.so`. library `gslcblas` is listed in `extra-libraries` of the `hmatrix-gsl` package: {{{ ghc-pkg field hmatrix-gsl extra-libraries extra-libraries: gsl gslcblas m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 16:08:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 16:08:23 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.18660f72e962e12da8c369f580af4529@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 16:44:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 16:44:30 -0000 Subject: [GHC] #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault In-Reply-To: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> References: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> Message-ID: <065.49639bba7c6fe70a0ca71d8caa4e0115@haskell.org> #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: llvm integer- | gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): More evidence this is C FFI related: the crash does not happen with `integer-simple` and LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:06:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:06:06 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.5183c2e9730abc6f9f1ef16fe1157943@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I established with Ryan that I can reproduce this on nix but he can't on a normal linux distribution where `libgsl` is installed globally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:09:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:09:03 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.0aa0d49de81ed3443c2df4cc1ed5f0d8@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Log of `ghc -fexternal-interpreter -package hmatrix-gsl Foo.hs -opti -v` https://gist.github.com/mpickering/507c62e15cea344ae90b8026b6a53d2e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:19:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:19:25 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.1a32b8fcf67d1568f1349fd863c797c4@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If you swap `gsl` and `gslcblas` does it fix the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:34:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:34:10 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.3137d71d6fe59b3c32c41ecff41ecf42@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If I add a dependency between `libgsl.so` and `libgslcblas.so` then it works. {{{ patchelf --add-needed /nix/store/6dhcmmfgy5fa0p3d235yaz4qfx8jhpar- gsl-2.5/lib/libgslcblas.so /nix/store/6dhcmmfgy5fa0p3d235yaz4qfx8jhpar- gsl-2.5/lib/libgsl.so readelf /nix/store/6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgsl.so -a | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [/nix/store /6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgslcblas.so] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:46:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:46:39 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail Message-ID: <047.ee50015c31757be835f8de5387a42628@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Keywords: Big-endian | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime primops/should_run/ArithInt16, | Blocked By: primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 | Blocking: | Related Tickets: #16222 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The tests were run on a PowerMac G5 running Linux, PowerMacs are big- endian. I reduced the issue to this program where I get the incorrect answer `25132`: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import GHC.Exts main :: IO () main = do putStrLn $ show (apply2 plusInt16# (50) (50)) apply2 :: (Int16# -> Int16# -> Int16#) -> Int -> Int -> Int apply2 op (I# a) (I# b) = let (# sa, sb #) = (# narrowInt16# a, narrowInt16# b #) r = op sa sb in I# (extendInt16# r) {-# NOINLINE apply2 #-} }}} Curiously, when I inline `plusInt16#` and remove the op parameter the result is correct. The test passes on little-endian PowerPC 64-bit. Note: This is bug is different form #16222 that deals with the C calling convention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 17:48:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 17:48:12 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.5a26d672dc8905cf96ac64d3de8984d2@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I am going to look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:09:53 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:09:53 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.a8b7bed76b717b6358d0f6ef63fff563@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Replying to [comment:16 josef]: > In fact, I think that this ticket should be split up so that we have a separate ticket for ApplicativeDo. The remedies for parallel monad comprehension and ApplicativeDo seem very different. I'll create a new ticket for ApplicativeDo unless someone yells. FWIW, I certainly have no objections, apologies if I made a mistake in linking the issues in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:16:24 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:16:24 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.4c601a15559be4e731aa62c4291b3d0b@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/260 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/260 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:17:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:17:52 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.685970fb7ec17488634fa4e081e26944@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): @mpickering, thank you for the workaround. Do you think this can be considered as a packaging issue (of `libgsl`)? or is this still a ghc issue considering that it works without `-fexternal-interpreter`? I tried to flip `gsl` and `gslcblas` in `external-libraries` and it does not change anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:18:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:18:58 -0000 Subject: [GHC] #16259: Hadrian does not work with a cabal v2-installed "happy" Message-ID: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> #16259: Hadrian does not work with a cabal v2-installed "happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I installed happy with: {{{ cabal new-install --symlink-bindir=~/Software/ghc-8.6.3/bin happy }}} where `~/Software/ghc-8.6.3/bin` is in my PATH. When I run `hadrian/build.sh -c --flavour=devel2` I get the following error: {{{ happy: /home/roland/.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9 /HappyTemplate-arrays-coerce: openFile: does not exist (No such file or directory) }}} It's correct, I don't have a file `.cabal/share/x86_64-linux- ghc-8.6.3/happy-1.19.9/HappyTemplate-arrays-coerce`. However I have a file `.cabal/store/ghc-8.6.3/happy-1.19.9-84db80555b9a8f54be2ca475bccbc751401ffbff30194c8c26d08a002a665431/share /HappyTemplate-arrays-coerce`. If I do an old-fashioned `cabal v1-install happy`, it creates the missing file `.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9/HappyTemplate- arrays-coerce` and Hadrian is now able to build! Hadrian should not depend on old-style cabal installs! Program versions: {{{ roland at goms:~/Projekte/ghc$ cat /etc/issue Debian GNU/Linux 9 \n \l roland at goms:~/Projekte/ghc$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 roland at goms:~/Projekte/ghc$ hadrian/build.sh --version Up to date Shake build system, version 0.17.4 roland at goms:~/Projekte/ghc$ happy --version Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. roland at goms:~/Projekte/ghc$ cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:30:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:30:44 -0000 Subject: [GHC] #16259: Hadrian does not work with a cabal v2-installed "Happy" (was: Hadrian does not work with a cabal v2-installed "happy") In-Reply-To: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> References: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> Message-ID: <064.c2b62b42812ebd6afb042391318a5e01@haskell.org> #16259: Hadrian does not work with a cabal v2-installed "Happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RolandSenn: Old description: > I installed happy with: > > {{{ > cabal new-install --symlink-bindir=~/Software/ghc-8.6.3/bin happy > }}} > > where `~/Software/ghc-8.6.3/bin` is in my PATH. > > When I run `hadrian/build.sh -c --flavour=devel2` I get the following > error: > > {{{ > happy: /home/roland/.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9 > /HappyTemplate-arrays-coerce: openFile: does not exist (No such file or > directory) > }}} > > It's correct, I don't have a file `.cabal/share/x86_64-linux- > ghc-8.6.3/happy-1.19.9/HappyTemplate-arrays-coerce`. > > However I have a file > `.cabal/store/ghc-8.6.3/happy-1.19.9-84db80555b9a8f54be2ca475bccbc751401ffbff30194c8c26d08a002a665431/share > /HappyTemplate-arrays-coerce`. > > If I do an old-fashioned `cabal v1-install happy`, it creates the missing > file `.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9/HappyTemplate- > arrays-coerce` and Hadrian is now able to build! > > Hadrian should not depend on old-style cabal installs! > > Program versions: > > {{{ > roland at goms:~/Projekte/ghc$ cat /etc/issue > Debian GNU/Linux 9 \n \l > > roland at goms:~/Projekte/ghc$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.6.3 > > roland at goms:~/Projekte/ghc$ hadrian/build.sh --version > Up to date > Shake build system, version 0.17.4 > > roland at goms:~/Projekte/ghc$ happy --version > Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) > 1997-2005 Simon Marlow > > Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. > This program is free software; you can redistribute it and/or modify > it under the terms given in the file 'LICENSE' distributed with > the Happy sources. > > roland at goms:~/Projekte/ghc$ cabal --version > cabal-install version 2.4.1.0 > compiled using version 2.4.1.0 of the Cabal library > }}} New description: I installed Happy with: {{{ cabal new-install --symlink-bindir=~/Software/ghc-8.6.3/bin happy }}} where `~/Software/ghc-8.6.3/bin` is in my PATH. When I run `hadrian/build.sh -c --flavour=devel2` I get the following error: {{{ happy: /home/roland/.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9 /HappyTemplate-arrays-coerce: openFile: does not exist (No such file or directory) }}} It's correct, I don't have a file `.cabal/share/x86_64-linux- ghc-8.6.3/happy-1.19.9/HappyTemplate-arrays-coerce`. However I have a file `.cabal/store/ghc-8.6.3/happy-1.19.9-84db80555b9a8f54be2ca475bccbc751401ffbff30194c8c26d08a002a665431/share /HappyTemplate-arrays-coerce`. If I do an old-fashioned `cabal v1-install happy`, it creates the missing file `.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9/HappyTemplate- arrays-coerce` and Hadrian is now able to build! Hadrian should not depend on old-style cabal installs! Program versions: {{{ roland at goms:~/Projekte/ghc$ cat /etc/issue Debian GNU/Linux 9 \n \l roland at goms:~/Projekte/ghc$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 roland at goms:~/Projekte/ghc$ hadrian/build.sh --version Up to date Shake build system, version 0.17.4 roland at goms:~/Projekte/ghc$ happy --version Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. roland at goms:~/Projekte/ghc$ cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 18:53:29 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 18:53:29 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.3debda00b7af940de44e82f77d6dc6da@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think it's a bug in GHC but it's not clear to me why it works for Ryan but not for me. There isn't a dependency as you're meant to be able to use different libraries with `gsl` other than just `gslcblas` according to the documentation. https://www.gnu.org/software/gsl/manual/html_node/Linking- programs-with-the-library.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 19:46:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 19:46:54 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.5c6a2915024e04806bfc1b0572a6fb55@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): No, this is fine :) Lens generation shouldn't have problems on code front, because the splices should only ever refer to code in the lens package, which should be fully compiled at this point. But maybe the problem is we don't get good information about abstract data types at this time? I guess it would be good to see if this works at all or not at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 22:28:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 22:28:47 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.9af3abb15436d63a7fb7cde2efc9bc7d@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): Yeah remove the license file. My test case would be to add a datatype containing an `A` to https://github.com/LightAndLight/backpack- test/blob/master/library-a/B.hs, then generate lenses for it. Does that seem appropriate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 22:55:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 22:55:08 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.3ab5c575ee41a144c4bb6324efcb091c@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): This `Dockerfile` shows that indeed the problem does not appear on a "normal" system: {{{ FROM ubuntu:latest RUN apt-get update RUN apt-get install -y wget RUN wget -qO- https://get.haskellstack.org/ | sh RUN stack setup RUN apt-get install -y libgsl23 RUN apt-get install -y libblas-dev liblapack-dev RUN apt-get install -y pkg-config RUN stack install vector RUN apt-get install -y libgsl-dev RUN stack install hmatrix-gsl COPY Foo.hs /root/Foo.hs RUN stack ghc -- -package hmatrix-gsl -fexternal-interpreter /root/Foo.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 23:03:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 23:03:03 -0000 Subject: [GHC] #16245: GHC panic (No skolem info) with QuantifiedConstraints and strange scoping In-Reply-To: <050.e0d66715082b7391c2386e53a67a1579@haskell.org> References: <050.e0d66715082b7391c2386e53a67a1579@haskell.org> Message-ID: <065.1178c9baf79a80346141f4ee7f67c19e@haskell.org> #16245: GHC panic (No skolem info) with QuantifiedConstraints and strange scoping -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Keywords: TypeInType, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 23:15:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 23:15:50 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.c365125734c0c499eeee906ebf114e7e@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Can you provide the output of `-opti -v` as well? (I'm disappointed your repro didn't use `buildFHSUserEnv`!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 23:30:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 23:30:03 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.657e08482d9c21f24d677b69f2edaab3@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): (It also fails in a `buildFHSUserEnv`, but I'm not really surprised, because even if the FHS is respected, it still uses most the nix link strategies and `rpath`.) `-opti -v` are there: https://gist.github.com/guibou/9bf3475faf00e4de0b5eb57247139921 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 30 23:34:04 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Jan 2019 23:34:04 -0000 Subject: [GHC] #16256: -fexternal-interpreter slow for profiling with template haskell In-Reply-To: <045.91f10a928f9d3a1420230057242969f8@haskell.org> References: <045.91f10a928f9d3a1420230057242969f8@haskell.org> Message-ID: <060.0cae1b40776031bfa15dbeb6b64f47c2@haskell.org> #16256: -fexternal-interpreter slow for profiling with template haskell -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): Note: I tried with ghc-8.6.3 in an ubuntu docker too, and the timing are consistent (1.2s versus 19s.). I checked to avoid reporting a `nixos` specific issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 00:36:06 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 00:36:06 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.6efbc575ba24aa27b6b5af4ac257e324@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15813 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I think an improvement would be to be able to disable the warning for the single function rather than module-wide. This way it can also serve as sort of a documentation thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 01:32:43 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 01:32:43 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.8c5e1621a6c785231dbee1518853f596@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, | Phab:D5229, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/261 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D4264, Phab:D5229 => Phab:D4264, Phab:D5229, https://gitlab.haskell.org/ghc/ghc/merge_requests/261 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 01:42:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 01:42:41 -0000 Subject: [GHC] #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault In-Reply-To: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> References: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> Message-ID: <065.5ad522f41e114b50bbe9585632c564a4@haskell.org> #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: llvm integer- | gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, yesterday I briefly investigated a related failure in `T15502` in #16087. Unfortunately I found that, unsurprisingly, it will be a nontrivial issue to debug and put it aside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 01:53:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 01:53:39 -0000 Subject: [GHC] #15632: Undependable Dependencies In-Reply-To: <043.01997ce1746c591111a0a2273155036b@haskell.org> References: <043.01997ce1746c591111a0a2273155036b@haskell.org> Message-ID: <058.4677cd47cfec9a30ee1c37fdd95779d7@haskell.org> #15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | FunctionalDependencies, | OverlappingInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 9210, | Differential Rev(s): 8634, 15135, 15927, 9627, 16070, | 16241 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * related: 10675, 9210, 8634, 15135, 15927, 9627, 16070 => 10675, 9210, 8634, 15135, 15927, 9627, 16070, 16241 Comment: Linking #16241, which is a follow-on from #15135. Under separate compilation, `OVERLAPPABLE` gives better coherence than `OVERLAPPING`. But it's fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 01:54:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 01:54:33 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.d72a5f67e9c2deca9d2e87f008be98f7@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): Okay, I've thought about this for a little bit: Why shouldn't the implication constraint be considered part of `quant_pred_candidates`? It seems to me that the error is in discarding it as a candidate in the first place. In other words, I would expect `g`'s inferred type to be `(forall x. Eq x => Eq (f x)) => A f -> A f -> Bool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 03:00:37 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 03:00:37 -0000 Subject: [GHC] #16154: -Wredundant-constraints: False positive In-Reply-To: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> References: <047.e34e45baaeb1aef52e67488fcc531f4c@haskell.org> Message-ID: <062.8627d58dff715b74772271dbcde753c8@haskell.org> #16154: -Wredundant-constraints: False positive -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15813 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Some variant of [[Design/LocalWarningPragmas]] might be a good way to accomplish this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 05:21:13 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 05:21:13 -0000 Subject: [GHC] #16233: HIE file generation is inefficient In-Reply-To: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> References: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> Message-ID: <065.42a220af256b4ad766510a52eea201a3@haskell.org> #16233: HIE file generation is inefficient -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15320 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * related: => #15320 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 05:31:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 05:31:04 -0000 Subject: [GHC] #16206: Run Haddock's test suite in CI In-Reply-To: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> References: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> Message-ID: <061.f02813818f8ebc5cdaee981f132fe656@haskell.org> #16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): This should be pretty achievable. In particular, the `html-test`, `latex- test`, `hypsrc-test`, and `hoogle-test` testsuites don't have large dependencies. In fact, the only extra library we would need to build would be the very stable and small `xml`. If someone with some experience hacking on GHC's testsuite could advise, I'd be happy to take this on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 06:10:32 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 06:10:32 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.62ce3d9912bc2dc32407c27ba306e70f@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): I've tried to implement the advice as described: excluding variables from generalisation when they appear in un-quantifiable constraints (collecting said variables in `approximateWC`, and removing them from `qtvs` in `simplifyInfer`). I now have an escaped skolem error. I think this is the relevant portion of the trace: {{{ {f1_a26[sk:1], f_a2c[sk:2]} g_ah :: forall (a :: (* -> *) -> *). a f_a2c[sk:2] -> a f_a2c[sk:2] -> Bool, eqA'_a28 :: a_a27[sk:1] f_a26[sk:1] -> a_a27[sk:1] f_a26[sk:1] -> Bool, eqA :: forall (f :: * -> *) (a :: (* -> *) -> *). (forall x. Eq x => Eq (f x)) => a f -> a f -> Bool, }}} Is it likely that I've forgotten some important call? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 06:20:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 06:20:27 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.af38761ef8403e8a32f333c57aa8c394@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by trommler: Old description: > The tests were run on a PowerMac G5 running Linux, PowerMacs are big- > endian. > > I reduced the issue to this program where I get the incorrect answer > `25132`: > {{{#!hs > {-# LANGUAGE BangPatterns #-} > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > > module Main where > > import GHC.Exts > > main :: IO () > main = do > putStrLn $ show (apply2 plusInt16# (50) (50)) > > apply2 :: (Int16# -> Int16# -> Int16#) -> Int -> Int -> Int > apply2 op (I# a) (I# b) = > let (# sa, sb #) = (# narrowInt16# a, narrowInt16# b #) > r = op sa sb > in I# (extendInt16# r) > {-# NOINLINE apply2 #-} > }}} > > Curiously, when I inline `plusInt16#` and remove the op parameter the > result is correct. > > The test passes on little-endian PowerPC 64-bit. > > Note: This is bug is different form #16222 that deals with the C calling > convention. New description: The tests were run on a PowerMac G5 running Linux, PowerMacs are big- endian. I reduced the issue to this program where I get the incorrect answer `25132`: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import GHC.Exts main :: IO () main = do putStrLn $ show (apply2 plusInt16# (50) (50)) apply2 :: (Int16# -> Int16# -> Int16#) -> Int -> Int -> Int apply2 op (I# a) (I# b) = let (# sa, sb #) = (# narrowInt16# a, narrowInt16# b #) r = op sa sb in I# (extendInt16# r) {-# NOINLINE apply2 #-} }}} Curiously, when I inline `plusInt16#` and remove the op parameter the result is correct. The test passes on little-endian PowerPC 64-bit. Note: This bug is different from #16222, which deals with the C calling convention. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 07:50:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 07:50:57 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail Message-ID: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Use of plugins will mark safe inference as failed, even when the plugin does not modify anything. This can result in compile error when -XSafe is used. For example: {{{ $ cat DefaultPlugin.hs module DefaultPlugin (plugin) where import GhcPlugins plugin = defaultPlugin $ cat B.hs {-# OPTIONS_GHC -fplugin DefaultPlugin #-} module B (answer) where answer = 42 $ cat A.hs {-# LANGUAGE Safe #-} module A (main) where import B main = print answer $ ... A.hs:4:1: error: B: Can't be safely imported! The module itself isn't safe. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 07:51:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 07:51:25 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.c25da16705d63f0f73bb02f19a5f0ada@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 08:08:30 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 08:08:30 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.d48cb0c42f962a2ca4a8225001bd4c49@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): In Cmm I find the following 16 bit store to the stack: {{{ R1 = _s1MY::P64; // CmmAssign I64[Sp] = stg_ap_n_info; // CmmStore I16[Sp + 8] = _s1N6::I16; // CmmStore call stg_ap_n_fast(R2, R1) args: 24, res: 8, upd: 8; // CmmCall }}} This is most likely wrong, it should probably be a 64 bit store. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:16:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:16:34 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.f44e7238876a94dd6706d4184b600982@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10712, #14998 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #10712, #14998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:20:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:20:34 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.171e7a42df2e26b69c2e30a8449e9b13@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Why shouldn't the implication constraint be considered part of quant_pred_candidates? It's always sound to quantify over any constraints you can't solve. But in many cases that'll simply push type errors from the definition site to the call site of the function. There are many constraints we don't quantify over as you'll see in `pickQuantifiableConstraints`. I think it's better (more explicit, more comprehensible) just to provide a type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:26:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:26:55 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.616e3b5faa7c0ceafa3ce30ca482d79b@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, | Phab:D5229, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/261 -------------------------------------+------------------------------------- Comment (by simonpj): To be clear * Phab:D4264 has landed (comment:9) * Phab:D5229 has landed (comment:19) So the only remaining issue is [https://gitlab.haskell.org/ghc/ghc/merge_requests/261 MR 261] "Fix #14579 by defining tyConAppNeedsKindSig, and using it" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:42:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:42:12 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning Message-ID: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:43:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:43:38 -0000 Subject: [GHC] #14998: Sort out the strictness mess for exceptions In-Reply-To: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> References: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> Message-ID: <061.0947356593245b1eb37e834630f5b003@haskell.org> #14998: Sort out the strictness mess for exceptions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Exceptions, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11555 #13330 | Differential Rev(s): #10712 #11222 #13380 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:32 dfeuer]: > I realized something. The `ExnStr` + `ThrowsExn` idea is the wrong idea ''for its purpose'', but it might be the right idea for a ''different'' purpose. Its goal (as I understand it) was to let us say that > > {{{#!hs > m `catch` h > }}} > > is sort of strict in `m`, and therefore we can evaluate `m` somewhat eagerly. This didn't work out, because we don't have enough information to do it right. However, what it ''should'' let us do correctly is a certain amount of dead code elimination. In particular, if we see that `m` definitely ''diverges'' (without throwing an exception), then we can simplify `catch m h` to `m`. But I'm betting this benefit isn't worth the complexity. I'm currently messing with Demand Analysis again and ExnStr has become a huge pain. I'll prepare a patch to remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:44:26 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:44:26 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.2a926e9b4949a6220e8b87b46581e921@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: This is already fixed in 8.8 by the addition of the `-fno-safe-haskell` flag. See #15920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:46:40 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:46:40 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.b636e2e4f1f8ab1f470de6d26a9d5d37@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think it's because of the overloaded list `[1]` which desugars to a call to `fromListN`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:47:59 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:47:59 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.262f5e1d47aee66d71a479ebf68facb5@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 mpickering]: > I think it's because of the overloaded list `[1]` which desugars to a call to `fromListN`. That's ... not a list. It's a rule phase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:48:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:48:38 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.3a81a1f89277925cdf06eee0b00a77ec@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > Compiling `Data.Set.Internal` produces the following: > > {{{ > Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] > Rule "Set.toAscListBack" may never fire > because rule "Class op fromListN" for ‘GHCExts.fromListN’ might > fire first > Probable fix: add phase [n] or [~n] to the competing rule > | > 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] > Rule "Set.toDescListBack" may never fire > because rule "Class op fromListN" for ‘GHCExts.fromListN’ might > fire first > Probable fix: add phase [n] or [~n] to the competing rule > | > 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = > toDescList #-} > | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > What the heck does the class op rule for `fromListN` have to do with > anything anywhere near here? New description: Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? Note in particular that this module neither defines `fromListN` (it takes its default definition) nor uses it in code or `RULES`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:51:09 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:51:09 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.debe45335091507b694dc93c370133cc@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Oops, how about `[]` then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:52:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:52:15 -0000 Subject: [GHC] #14998: Sort out the strictness mess for exceptions In-Reply-To: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> References: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> Message-ID: <061.ae76a252c56bca158e121d08dce567f8@haskell.org> #14998: Sort out the strictness mess for exceptions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Exceptions, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11555 #13330 | Differential Rev(s): #10712 #11222 #13380 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm currently messing with Demand Analysis again and ExnStr has become a huge pain. I'll prepare a patch to remove it. Hurrah. That's Item 1 from the Description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:53:18 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:53:18 -0000 Subject: [GHC] #16261: Mysterious rule shadowing warning In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.de565e9931e6be3b92b82e54289bad8a@haskell.org> #16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes, that's it. But the module doesn't even enable `OverloadedLists`. And why would we ''ever'' want `[]` to be interpreted as an overloaded list on a rule LHS? That makes no sense at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 09:55:59 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 09:55:59 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS (was: Mysterious rule shadowing warning) In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.2e908bed21bd1f86ea915a7d8b12b075@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > Compiling `Data.Set.Internal` produces the following: > > {{{ > Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] > Rule "Set.toAscListBack" may never fire > because rule "Class op fromListN" for ‘GHCExts.fromListN’ might > fire first > Probable fix: add phase [n] or [~n] to the competing rule > | > 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] > Rule "Set.toDescListBack" may never fire > because rule "Class op fromListN" for ‘GHCExts.fromListN’ might > fire first > Probable fix: add phase [n] or [~n] to the competing rule > | > 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = > toDescList #-} > | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > What the heck does the class op rule for `fromListN` have to do with > anything anywhere near here? Note in particular that this module neither > defines `fromListN` (it takes its default definition) nor uses it in code > or `RULES`. New description: Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} As mpickering figured out, the trouble is that `[]` in the rule LHS is being interpreted as an overloaded list. The module does ''not'' enable `OverloadedLists`. Furthermore, even if it ''did'', I would argue that it is ''never'' correct to put one in a rule LHS, so we should always interpret `[]` as the empty list constructor in `RULES` left-hand sides. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 10:09:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 10:09:17 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.678bcdc45025704caf9b5818a1ba0673@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 8.6.3 => 8.6.2 Comment: The problem showed up somewhere between 8.4.3 and 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 10:09:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 10:09:52 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.ff702d4fe4e98c73358038129467810a@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I found the issue, patch is coming. Small integer values passed on the stack are not promoted to word size (stack slot size). We can get away with that on little endian systems where the small integer ends up in the Right (TM) place for a word size read. On big endian the small integer is written into the most significant bits of a word and the least significant bits contain random values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 10:14:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 10:14:54 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.81097f3986cca737b3d55d215f53efc8@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Strike that; it was there much earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 10:15:28 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 10:15:28 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.6698d7444d454022ae3880bb5a87453e@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 8.6.2 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 10:29:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 10:29:38 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.25eaff6d213036f662bc7267062d6414@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Yes, that's it. But the module doesn't even enable OverloadedLists. That is indeed odd. Digging into why would be v helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 11:41:48 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 11:41:48 -0000 Subject: [GHC] #16262: Hadrian: respect dynamicGhcPrograms Message-ID: <045.a205c1b586695ffcc676bcf3f8335360@haskell.org> #16262: Hadrian: respect dynamicGhcPrograms -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian | Operating System: Unknown/Multiple dynamic ghc programs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While `dynamicGhcPrograms` exists in Hadrian, it is not used to the extent that it's make counter part is used (`DYNAMIC_GHC_PROGRAMS`). All relevant logic from make should be implemented in Hadrian as well. A simple search for `DYNAMIC_GHC_PROGRAMS` is a good place to start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 13:02:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 13:02:33 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.6391e30334abbc28f2cf8145d587e370@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, | Phab:D5229, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/261 -------------------------------------+------------------------------------- Comment (by simonpj): I've read the patch, but I'm commenting here because Trac has greater longevity than code reviews. You have written a commendably detailed Note -- thank you. Still, it took me a solid hour of head-scratching to really understand it. Here are some thoughts that may (or may not) help to make it clearer. First, it took me ages reslise that `tyConAppNeedsKindSig` can be done without knowing the actual arguments to `T`. Only once I'd realised that did I discover that, sure enough, it doesn't rely on `args`, only on `length args`! So I ''strongly'' suggest {{{ tyConAppNeedsKindSig :: Bool -- ^ Should specified binders count towards injective positions in -- the kind of the TyCon? -> TyCon -> Int -- Number of args -> Bool -- Does (T t1 .. tn) need a signature tyConAppNeedsKindSig spec_inj_pos tc n_args = ... }}} That is, pass the ''number'' of args, not the actual args. That makes it clear that the function could, in principle, live in `TyCon`. It could even be cached in the TyCon, as a list of `Bools` or, because of the Inferred/Specified thing, two lists of `Bools`. But the caching is probably not worth it. Ok then, my thought process went like this. Given a application `T t1 .. tn`, does it need a kind signature? Why might it need a kind signature? So that we can fill in any of T's omitted arguments. By an "omitted argument" I mean one that we do not reify expicitly in the `HsType`. Sometimes the omitted ones are Inferred ones (in `typeToHsType`); sometimes both Inferred and Specified (in `TcSplice`); but the key thing is that they don't appear in the `HsType`. What do we mean by "fill in"? Suppose {{{ T :: forall {k}. Type -> (k->*) -> k }}} and we have the application `T {j} Int aty`. When we convert to `HsType` we are going to omit the inferred arg `{j}`. Is it fixed by the other non-inferred args? Yes: if we know the kind of `aty :: blah`, we'll generate an equality constraint `(kappa->*) ~ blah` and, assuming we can solve it, that will fix `kappa`. (Here `kappa` is the unification variable that we instantiate `k` with.) So the question becomes this. * Consider the first `n` args of T: do the kinds of the non-omitted arguments determine the omitted arguments? We'll only handle the case were the omitted arguments are `NamedTCB`, so we need to determine a variable. When does a kind "determine" a variable? This is what `injectiveVarsOfType` computes. {{{ -- (See @Note [Kind annotations on TyConApps]@ in "TcSplice" for an explanation -- of what an injective position is.) injectiveVarsOfType :: Type -> FV }}} Rather than speak of "injective positions" I think of it like this: if `a` is in `injectiveVarsOfType ty` then knowing `ty` fixes, or determines, `a`. More formally: {{{ If a is in (injectiveVarsOfType ty) and S1(ty) ~ S2(ty) then S1(a) ~ S2(a) where S1 and S2 are arbitrary substitutions }}} For example, if `F` is a non-injective type family, then {{{ injectiveTyVarsOf( Either c (Maybe (a, F b c)) ) = {a,c} }}} (This part about `injectiveVarsOfType` is not new -- but I'd suggest adding it as comments to the function.) So we can refine the question: * Consider the first `n` args of T, and each omitted argument `i <= n`: is argument `i` a `NamedTCB` binder `b`, and does `b` appear in `injectiveVarsOfTtype (k(i+1) .. k(n))`? Where `kj` is the kind of the j'th argument of T. Much of this is as you have it, except that I'm not lookin at `result_kind` (in your `tyConAppNeedsKindSig`. If I can't fill in all omitted arguments, I'll add a kind signature. So for a silly thing like {{{ T :: forall k. Type -> Type }}} and the type `(T {j} Int)`, I'll add a kind signature, which actually does no good since `k` is unused. But it's a silly example. And you'll add one for a different silly example. {{{ T :: forall k. Type -> F k }}} which equally does no good. Nothing here is radically different from what you have. But I find the chain of thought here easier to follow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 13:39:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 13:39:14 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.64f49f04c76ceaeb7b4d3b4ed3908f22@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes to two tickets. So we have * '''Parallel monad comprehensions''': no difficulty in principle, but `tcSyntaxOp` needs to do impredicative instantiation. See comment:14 * '''ApplicativeDo'''. New ticket needed. I strongly suggest that Step 1 is to take the presentation in the paper and extend it to handle `let` statements. Then it may be clearer what to do. Probably nothing to do with impredicativity. Note also Simon's comment that "I also have a suspicion that we're not treating the last statement of the do in the way that the paper suggests - adding an extra return statement if the last statement is not a return." It would be good to clean this up too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 13:51:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 13:51:12 -0000 Subject: [GHC] #16249: no runtime error for -fdefer-type-errors with TypeError constraint In-Reply-To: <045.626de93e9953e5037e13e5097ffe4ce4@haskell.org> References: <045.626de93e9953e5037e13e5097ffe4ce4@haskell.org> Message-ID: <060.38a3c3a638a5ce5f4560bb41d704b822@haskell.org> #16249: no runtime error for -fdefer-type-errors with TypeError constraint -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. The trouble here is that, at runtime the `TypeError` dictionary is not actually used. I think we get something like this {{{ data Foo t = MkFoo (t -> t) foo :: Foo t -> t -> t foo (MkFoo f) = f $dfFooString :: TypeError (Text "String does not work") -> Foo String -- Arises from the instance $dfFooString d = MkFoo id derr:: TypeError (Text "String does not work") derr = error "String does not work" x :: String -- Haskell source code: -- x = foo "hello" x = foo ($dfFooString derr) "hello" }}} Evaluating `f` does not evaluate `derr`, hence the no-error run. I suppose someone could think about evaluating calls to `TypeError` more eagerly. But I'd be inclined to think that an easier path is to say {{{ instance (TypeError (Text "String does not work")) => Foo String where foo = error "String does not work" }}} I'm sure there is more than could be done to make `TypeError` better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 13:53:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 13:53:14 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.f8e23626be11fc458c624cc94950c703@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, to be clear then, your proposal is that: * `CoVars ` must have `(~#)` types * But non `CoVars` can have `(~#)` types too Is that what you are saying? That's ok with me. But `core-spec/` would need updating to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 14:45:33 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 14:45:33 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.ce51863e1e107afa7e8ca4f2c237c436@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): It seems the patch from the MR was incompletely applied. https://gitlab.haskell.org/ghc/ghc/commit/4bf35da4fccd2a21153a1c19bfa80006e99e02a1 landed on master, whereas https://gitlab.haskell.org/ghc/ghc/merge_requests/205/diffs?commit_id=5e0e60403e5ad6730f4961fe92b569dd2bf30246 is the diff that was referenced in the MR. The latter passed the tests, but the former breaks CI because T16212 is not marked as expected to pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 15:01:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 15:01:42 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.29a25081091627db8b6dcd7224a210d6@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is the diff of the two diffs: {{{#!patch --- /tmp/orig.diff 2019-01-31 15:46:25.327999736 +0100 +++ /tmp/master.diff 2019-01-31 15:52:36.222476816 +0100 @@ -253,24 +253,17 @@ + +data Foo (a) b = Foo { av :: a, bv :: b } diff --git a/testsuite/tests/ghc-api/annotations/all.T b/testsuite/tests /ghc-api/annotations/all.T -index 49f0780021..4bb72926ca 100644 +index 97c3c60c21..8002630b53 100644 --- a/testsuite/tests/ghc-api/annotations/all.T +++ b/testsuite/tests/ghc-api/annotations/all.T -@@ -38,8 +38,7 @@ test('T10399', [extra_files(['Test10399.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T10399']) +@@ -38,9 +38,7 @@ test('T10399', [extra_files(['Test10399.hs']), + ignore_stderr], makefile_test, ['T10399']) test('T10313', [extra_files(['Test10313.hs', 'stringSource.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T10313']) + ignore_stderr], makefile_test, ['T10313']) -# Stricter tests from trac #16217 now causes this to fail. Will be fixed for trac #16212 --test('T11018', [expect_broken(11018),extra_files(['Test11018.hs']), +-test('T11018', [expect_broken(11018), +- extra_files(['Test11018.hs']), +test('T11018', [extra_files(['Test11018.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T11018']) + ignore_stderr], makefile_test, ['T11018']) test('bundle-export', [extra_files(['BundleExport.hs']), - ignore_stderr], run_command, ['$MAKE -s --no- print-directory bundle-export']) -@@ -60,6 +59,5 @@ test('T13163', [extra_files(['Test13163.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T13163']) - test('T15303', [extra_files(['Test15303.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T15303']) --# Stricter tests from trac #16217 now causes this to fail. Will be fixed for trac #16212 --test('T16212', [expect_broken(16212),extra_files(['Test16212.hs']), -+test('T16212', [extra_files(['Test16212.hs']), - ignore_stderr], run_command, ['$MAKE -s --no-print- directory T16212']) + ignore_stderr], makefile_test, ['bundle-export']) }}} Appearently `makefile_test` is a new short-hand for `$MAKE -s --no-print- directory {target}` and the bottom part just re-activates T16212. I re-applied that part in https://gitlab.haskell.org/ghc/ghc/merge_requests/266. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 15:02:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 15:02:17 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.61b65be1d7f35a6bcddd00038542f4b1@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 15:23:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 15:23:52 -0000 Subject: [GHC] #16238: Hadrian provides no way to accept output of test In-Reply-To: <049.1873139ea1b4f6b0248689aa8bba7e65@haskell.org> References: <049.1873139ea1b4f6b0248689aa8bba7e65@haskell.org> Message-ID: <064.0f0d6482b9c2318e0d2847e5c2398d35@haskell.org> #16238: Hadrian provides no way to accept output of test -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: In particular it also needs to support all the overloads accept does, such as `OS=YES`, `PLATFORM=YES` etc. Otherwise it makes updating platform specific failures quite painful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 15:38:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 15:38:05 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.421b90248dcb8eb0124f9da2e22ce683@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Actually I do think that `ApplicativeDo` has a similar problem to parallel list comprehensions. It's true that in the example given in comment:5 above we could fix `ApplicativeDo` to do a slightly different transformation and not run into the problem. But that won't work in general, e.g. {{{ test :: IO (Int, Char, Int) test = do x <- return 'a' y <- return 'a' let f | y == 'c' = id | otherwise = id z <- return (f 3) return (f 3, f 'a', z) }}} This is accepted without `ApplicativeDo`, but rejected with it, because we need `f` to be polymorphic. The renamer produces: {{{ ==================== Renamer ==================== Test.test :: IO (Int, Char, Int) Test.test = do x_a3Dl <- return 'a' | (f_a3Dn, z_a3Do) <- do y_a3Dm <- return 'a' let f_a3Dn | y_a3Dm == 'c' = id | otherwise = id z_a3Do <- return (f_a3Dn 3) (f_a3Dn, z_a3Do) return (f_a3Dn 3, f_a3Dn 'a', z_a3Do) }}} so we would need to instantiate the tuple type with polymorphic arguments. Simon - I vaguely remember that we discussed this when reviewing the code for ApplicativeDo and we decided to punt on it at the time, but unfortunately I can't find any record of it, do you remember by any chance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 15:43:47 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 15:43:47 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.8fd818d393cea968fc4f25e572524c1f@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Simon - I vaguely remember that we discussed this when reviewing the code for ApplicativeDo and we decided to punt on it at the time, but unfortunately I can't find any record of it, do you remember by any chance? I had a quick look but didn't find anything, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 16:26:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 16:26:31 -0000 Subject: [GHC] #12092: Out-of-scope variable leads to type error, not scope error In-Reply-To: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> References: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> Message-ID: <057.b2aa7b3d0044e3bae0dc20c05d00add2@haskell.org> #12092: Out-of-scope variable leads to type error, not scope error -------------------------------------+------------------------------------- Reporter: kwf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dbaynard): I'm seeing this on 8.6.3 (even with `-fno-defer-type-errors`). Note: my ghc install is managed by stack. == Without application {{{ > cat type-app-err.hs {-# LANGUAGE TypeApplications #-} module Bug where huh = spam > ghc -fno-defer-type-errors type-app-err  16:19:10 [1 of 1] Compiling Bug ( type-app-err.hs, type-app-err.o ) type-app-err.hs:5:7: error: • Variable not in scope: spam • Perhaps you meant ‘span’ (imported from Prelude) | 5 | huh = spam | ^^^^ }}} == Without application {{{ > cat type-app-err.hs {-# LANGUAGE TypeApplications #-} module Bug where huh = spam @Int > ghc -fno-defer-type-errors type-app-err  16:19:18 [1 of 1] Compiling Bug ( type-app-err.hs, type-app-err.o ) type-app-err.hs:5:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: spam @Int In an equation for ‘huh’: huh = spam @Int | 5 | huh = spam @Int | ^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 16:57:37 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 16:57:37 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind Message-ID: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6 accepts {{{#!hs data Q :: Eq a => Type }}} It shouldn't, as we can't have `Eq a` as a constraint in kinds. Note that writing a constructor for `Q` is rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 17:05:44 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 17:05:44 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.0ca6bb2d6f71c2f8816cc663fb2b569e@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): IIRC part of the reason that the `make` build system behaves "correctly" here is that the testsuite rule is essentially decoupled from the rest of the build system: it has no dependencies whatsoever. You can observe this by running `make test` in a clean tree. You will find that it makes no attempt to build anything but rather just starts in on running the testsuite, using whatever GHC it finds on the path. There is actually a good reason for this: the testsuite can be run against any GHC, not only one from a GHC working directory. As to whether Hadrian should emulate this, I'm torn. Certainly we should have **some** target for running the testsuite against an arbitrary out- of-tree GHC. However, it would make sense if `hadrian test` tested the current working directory. I think the real root of the problem here is that it's very easy to forget adding `--freeze1` to the command line. Perhaps having a way to persist this setting would alleviate much of the pain associated with unintended rebuilds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 17:17:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 17:17:11 -0000 Subject: [GHC] #16264: Install reqlib'd libraries during CI Message-ID: <046.782847618c93060689478051686a30cf@haskell.org> #16264: Install reqlib'd libraries during CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently tests requiring external libraries are hardly ever run. We likely don't want to run them in every job but we should have at least one job that makes a point of doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 17:20:36 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 17:20:36 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.f50ab27b586e7f9a0891b225983d2df9@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > I think the real root of the problem here is that it's very easy to forget adding `--freeze1` to the command line. Perhaps having a way to persist this setting would alleviate much of the pain associated with unintended rebuilds. We could indeed make it possible to set `--freeze1`, or more generally `--skip` any set of dependencies, by modifying the default build flavour in `UserSettings.hs`. This requires the user to make some initial changes in their `UserSettings` file, but after that any `build` command will rebuild exactly what they asked. Does this sound like the right approach? I think implementation-wise, this is quite easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 17:22:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 17:22:11 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.ef2cff07abe8754337f08d1f75e33b7b@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10712, #14998 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): #14998 suggests that we have the performance gains without actually making `catch#` and `catchRetry#` any more special than necessary. I think we can close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 17:51:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 17:51:38 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.248b95e878247787ac720fdbf76ff94b@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Can we also make a `--freeze2` setting, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:02:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:02:14 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.657a64d50f09ccc94f71b2886ce7b054@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Can we also make a `--freeze2` setting, then? Do you mean add a command line flag `--freeze2`, or allow the user to achieve the same effect in `UserSettings`? Both are relatively easy, but I'd like to clarify what you meant exactly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:04:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:04:12 -0000 Subject: [GHC] #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) In-Reply-To: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> References: <050.48200f48acc6a5058d557a6e246a902a@haskell.org> Message-ID: <065.8f9af84ca69f464263bc264be16d43f4@haskell.org> #16246: GHC HEAD-only Core Lint error with unboxed equality (Non-CoVar has coercion type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15648 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that's what I'm saying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:05:44 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:05:44 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.996fe822f5461cf99495a33d292ebaf7@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Both. Once all these features land, I anticipate spending some time creating my own scripts to make it easy to, e.g., switch flavors and specify these flags. Then, I should be able to customize the workflow nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:06:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:06:23 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.74a17ca55ab823723ed7dedf01758978@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Does this sound like the right approach? I think implementation-wise, this is quite easy. Sounds like a good start to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:20:39 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:20:39 -0000 Subject: [GHC] #12092: Out-of-scope variable leads to type error, not scope error In-Reply-To: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> References: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> Message-ID: <057.7ee4483af88f058bde075a037a41b71d@haskell.org> #12092: Out-of-scope variable leads to type error, not scope error -------------------------------------+------------------------------------- Reporter: kwf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh dear, that is a good observation. It seems that this has regressed at some point between 8.4 and 8.6. Since #13834 is basically the same issue, let's move the discussion about this problem to there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:22:36 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:22:36 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.65b152c6a579a0953a40281bfcedbccf@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12794 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As dbaynard noted in https://ghc.haskell.org/trac/ghc/ticket/12092#comment:4, things are even worse on GHC 8.6 than they used to be. That is, while you'd get these errors on GHC 8.4.4: {{{ $ /opt/ghc/8.4.4/bin/ghc -XTypeApplications -e "notInScope @Bool" :0:1: error: Variable not in scope: notInScope :0:1: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ • In the expression: notInScope @Bool In an equation for ‘it’: it = notInScope @Bool }}} You don't even get the `Variable not in scope` error on GHC 8.6.3: {{{ $ /opt/ghc/8.6.3/bin/ghc -XTypeApplications -e "notInScope @Bool" :0:1: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ • In the expression: notInScope @Bool In an equation for ‘it’: it = notInScope @Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 18:31:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 18:31:42 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.1a2e85ce641dd1ecfe94ff59b4dccf4d@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, newcomer * milestone: => 8.8.1 Comment: Luckily, commit 2257a86daa72db382eb927df12a718669d5491f8 (`Taming the Kind Inference Monster`) has already fixed this in GHC HEAD: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive -XPolyKinds -XDataKinds GHCi, version 8.7.20190128: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import Data.Kind λ> data Q :: Eq a => Type :2:1: error: Illegal constraint in a kind: Eq a => * }}} We just need a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 19:18:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 19:18:17 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.9162386ee32fecf706d16ca981c0330d@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): @mpickering Thanks, I didn't notice there was already a similar ticket. `-fno-safe-haskell` would resolve the compilation issue in the ticket, but we still gets inconsistent `TcGblEnv`. For more background, I am trying to use source plugins to implement paralleled haddock, and this will generate wrong "Safe Haskell" information even we don't make any change. As you commented in #15920 > I'm not that enthusiastic about a proposal as I don't know that anyone should rely on safe haskell as it's quite a neglected feature. I think I would rather write a proposal about removing safe haskell rather than understand how it should interact more precisely with plugins. In this case, do you think it makes sense to simply remove calls of `mark_plugin_unsafe` in `renamed/typeCheckResultAction` https://gitlab.haskell.org/ghc/ghc/blob/c2455e64/compiler/typecheck/TcRnDriver.hs#L2877 and push the responsibility of calling `recordUnsafeInfer` to the plugin author and document this somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 20:23:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 20:23:57 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.e3e55266eedd794e992d6da6e4d0976a@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm sympathetic to this but the fact is a plugin can arbitrarily change `TcGblEnv` so the only option is to mark the affected modules as `Unsafe`. Perhaps a better solution is to make all the fields which can modify the AST return `Maybe` so that if any modifications take place then the module is marked `Unsafe`. Plugins can return `Nothing` if they want to purely inspect information. I'm reluctant to do this though purely to satisfy safe haskell checks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 20:42:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 20:42:15 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.109f49766ae0abd294a975fe2d37af78@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): > Perhaps a better solution is to make all the fields which can modify the AST return Maybe so that if any modifications take place then the module is marked Unsafe. Plugins can return Nothing if they want to purely inspect information. I thought about this as well. But `keepRenamedSource` is a useful couterexample that modifies the return value but doesn't affect the final output. I am not familiar with all the use cases of source plugins. Assuming we push the responsibility the plugin authors, how bad will it be if they forget calling `recordUnsafeInfer` when they should? Is this worse than `-fno-safe-haskell`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 20:43:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 20:43:07 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.9efb4a3f7b38fd17527a83c629ac89b2@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * cc: mpickering, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 20:49:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 20:49:57 -0000 Subject: [GHC] #16260: Use of plugins causes -XSafe to fail In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.c778586ed33ef468ca77179611c31306@haskell.org> #16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): My reasoning is that if a consumer decides that they don't care about Safe Haskell then they can use `-fno-safe-haskell` and skip the checks. However, if a user does care about safe haskell then they would care if one of their dependencies was modified with a plugin, this kind of situation is easy to achieve when using nix for example. If it is up to the plugin authors to be prudent, I imagine that none of them will be. Perhaps if we just modify the `Sf_Ignore` constructor to be `Sf_Ignore SafeHaskellMode` to record the mode it is ignoring then that would solve your problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 21:16:03 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 21:16:03 -0000 Subject: [GHC] #16260: Use of plugins causes different SafeHaskellMode returned for the module (was: Use of plugins causes -XSafe to fail) In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.f03d99e4e14b50c399a49ac5428250dd@haskell.org> #16260: Use of plugins causes different SafeHaskellMode returned for the module -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: watashi => (none) * status: closed => new * resolution: fixed => Comment: Your reasoning is very fair. If I understand correctly, `-fno-safe-haskell` works on the depender side and here we want to get the original `SafeHaskellMode` in the dependee side. So this will be something like `Sf_PluginUnsafe SafeHaskellMode` instead and it will definitely unblock me. Alternatively, how about an explicit flag (`-fplugin-safe-ignore`?) that will turn off `mark_plugin_unsafe`? As an explicit flag is passed, we assume users have clear idea what they are doing. Let me know what do you think. Reopen the ticket before we actually address this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 21:16:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 21:16:14 -0000 Subject: [GHC] #16260: Use of plugins causes different SafeHaskellMode returned for the module In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.9d74af3a26764ef03bdc2da498cd262f@haskell.org> #16260: Use of plugins causes different SafeHaskellMode returned for the module -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 21:20:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 21:20:21 -0000 Subject: [GHC] #16265: API Annotations: parens anns discarded for `(*)` operator Message-ID: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> #16265: API Annotations: parens anns discarded for `(*)` operator -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The patch from https://phabricator.haskell.org/D4865 introduces {{{#!hs go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix = do { warnStarBndr l ; let name = mkOccName tcClsName (if isUni then "★" else "*") ; return (cL l (Unqual name), acc, fix, ann) } }}} which discards the parens annotations belonging to the `HsParTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 21:20:35 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 21:20:35 -0000 Subject: [GHC] #16265: API Annotations: parens anns discarded for `(*)` operator In-Reply-To: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> References: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> Message-ID: <059.362b62b78cdbac4dc187d3bfc24c7b33@haskell.org> #16265: API Annotations: parens anns discarded for `(*)` operator -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 21:35:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 21:35:17 -0000 Subject: [GHC] #16260: Use of plugins causes different SafeHaskellMode returned for the module In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.61599a948c4d42a9153fc116341c304a@haskell.org> #16260: Use of plugins causes different SafeHaskellMode returned for the module -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I like your `-fplugin-safe-ignore` idea. That is more direct than my original patch. Do you think we should revert my `-fno-safe-haskell` patch and implement this instead? OTOH, a flag which disables `SafeHaskell` checks might be useful one day to unstick someone else so perhaps it is good to implement both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 22:11:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 22:11:05 -0000 Subject: [GHC] #16260: Use of plugins causes different SafeHaskellMode returned for the module In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.a58cbc5b66ee354cccab77ac995f8a89@haskell.org> #16260: Use of plugins causes different SafeHaskellMode returned for the module -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): Cool, I will make a change for this then. Personally, I leans a little bit on the reverting side just because I am not a big fan of too many flags. But I think those two are actually orthogonal even though they are originally built to address the same issue, and I will leave the decision to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 22:28:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 22:28:14 -0000 Subject: [GHC] #14998: Sort out the strictness mess for exceptions In-Reply-To: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> References: <046.d3096c43bf101ad7c81045eb41e2848f@haskell.org> Message-ID: <061.176b16f4a16131c3f8bacbdeb3a6b611@haskell.org> #14998: Sort out the strictness mess for exceptions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Exceptions, | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11555 #13330 | Differential Rev(s): #10712 #11222 #13380 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Over time we have evolved into a messy and bad place for the interaction > of strictness analysis and exceptions. > > Here's the amazing history of the strictness of `catch#` > > * Dec 13: 0558911f91c: catch# gets a strictness signature with > `lazyApply1Dmd` > * Jul 15: 7c0fff41789: catch# goes from `lazyApply1Dmd` to > `strictApply1Dmd` > * Dec 15: 28638dfe79e: catch# goes from `strictApply1Dmd` to > `lazyApply1Dmd`. Trac #10712 > * Jan 16: 9915b656440: catch# goes from `lazyApply1Dmd` to `catchArgDmd`, > and result goes from `botRes` to `exnRes` Trac #11222. > * Mar 17: 701256df88c: catch# goes from 'catchArgDmd` to `lazyApply1Dmd`. > This ticket #13330. > > See also > * The [wiki:Exceptions] page > * `Note [Strictness for mask/unmask/catch]` in `primops.txt/pp`. > * `exceptions_and_strictness` in `primops.txt/pp`. > * `Note [Exceptions and strictness]` in `Demand.hs` > * #11555, #13330, #10712, #11222 > > '''Item 1: ThrowsExn''' > > * The strictness analyser has quite a bit of complexity around > `ThrowsExn`. > * `ThrowsExn` only differs from `Diverges` if the `ExnStr` flag is set to > `ExnStr` > * And the only place that happens is in `Demand.catchArgDmd` > * The only place `catchArgDmd` is used is in `primops.txt.pp`. > Originally, in the patch for #11222, `catchArgDmd` was used for the first > arg of `catch#`, `catchSTM#` and `catchRetry#`. > * But the patch in this ticket removed two of those three; now only > `catchRetry#` uses the `catchArgDmd` thing. > > It looks to me as if `catchRetry#` was left out by mistake; and indeed > David says "I left it out on the grounds that I didn't understand it well > enough." > > And if so, that's the last use of `catchArgDmd` and I think that all the > tricky `ThrowsExn` machinery can disappear. > > '''Item 2: strictness of catchException''' > > As a result of all this to-and-fro we have in GHC.IO > {{{ > catch (IO io) handler = IO $ catch# io handler' > catchException !io handler = catch io handler > }}} > That is, `catchException` is strict in the IO action itself. But Neil > argues in #11555, commment:6 that this is bad because it breaks the monad > laws. > > I believe that there is some claimed performance gain from the strictness > of `catchException`, but I don't believe it exists. The perf gain was > from when it had a `strictApply1Dmd`; that is, it promised to call its > argument. See this note in `primops.txt.pp` > {{{ > -- Note [Strictness for mask/unmask/catch] > -- Consider this example, which comes from GHC.IO.Handle.Internals: > -- wantReadableHandle3 f ma b st > -- = case ... of > -- DEFAULT -> case ma of MVar a -> ... > -- 0# -> maskAsynchExceptions# (\st -> case ma of MVar a -> > ...) > -- The outer case just decides whether to mask exceptions, but we don't > want > -- thereby to hide the strictness in 'ma'! Hence the use of > strictApply1Dmd. > }}} > I think the above saga was all in pursuit of exposing the strictness of > `ma` if we used `catch#` instead of `maskAsynchExceptions#` in this > example. But the saga ultimate appears to have failed, and the > strictenss annotation in `catchException` is a vestige that carries no > benefit, but does requires comments etc. > > '''Item 3: performance''' > > If making `catch#` have strictness `strictApply1Dmd` improves perf, it > would be good to know where. That would entail making the (tiny) change, > recompiling all, and nofibbing. Here is the commit message in > 7c0fff41789, which added `strictApply1Dmd`: > {{{ > commit 7c0fff41789669450b02dc1db7f5d7babba5dee6 > Author: Simon Peyton Jones > Date: Tue Jul 21 12:28:42 2015 +0100 > > Improve strictness analysis for exceptions > > Two things here: > > * For exceptions-catching primops like catch#, we know > that the main argument function will be called, so > we can use strictApply1Dmd, rather than lazy > > Changes in primops.txt.pp > > * When a 'case' scrutinises a I/O-performing primop, > the Note [IO hack in the demand analyser] was > throwing away all strictness from the code that > followed. > > I found that this was causing quite a bit of unnecessary > reboxing in the (heavily used) function > GHC.IO.Handle.Internals.wantReadableHandle > > So this patch prevents the hack applying when the > case scrutinises a primop. See the revised > Note [IO hack in the demand analyser] > > Thse two things buy us quite a lot in programs that do a lot of IO. > > Program Size Allocs Runtime Elapsed > TotalMem > -------------------------------------------------------------------------------- > hpg -0.4% -2.9% -0.9% -1.0% > +0.0% > reverse-complem -0.4% -10.9% +10.7% +10.9% > +0.0% > simple -0.3% -0.0% +26.2% +26.2% > +3.7% > sphere -0.3% -6.3% 0.09 0.09 > +0.0% > -------------------------------------------------------------------------------- > Min -0.7% -10.9% -4.6% -4.7% > -1.7% > Max -0.2% +0.0% +26.2% +26.2% > +6.5% > Geometric Mean -0.4% -0.3% +2.1% +2.1% > +0.1% > }}} > If these gains are still on the table (i.e. moving to `strictApply1Dmd` > gives them), perhaps we can add some strictness annotations to the I/O to > replicate the effect, even if we'd decided we can't actualy make `catch#` > strict? > > '''Item 4: IO hack in the demand analyser''' > > In getting up to speed with this, I noticed this comment in the demand > analyser: > {{{ > {- Note [IO hack in the demand analyser] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > There's a hack here for I/O operations. Consider > > case foo x s of { (# s', r #) -> y } > > ...omitted... > > However, consider > f x s = case getMaskingState# s of > (# s, r #) -> > case x of I# x2 -> ... > > Here it is terribly sad to make 'f' lazy in 's'. After all, > getMaskingState# is not going to diverge or throw an exception! This > situation actually arises in GHC.IO.Handle.Internals.wantReadableHandle > (on an MVar not an Int), and made a material difference. > > So if the scrutinee is a primop call, we *don't* apply the > state hack... > }}} > Idea: in the nested-CPR work, we have simple termination information. So > we can use that, instead of "is a primop call" to deliver on this hack in > a much more principled way. > > '''Item 5: raiseIO#''' > > There is an unresolved question about whether `raiseIO#` should return an > exception result in its strictness signature. See Trac #13380, which > applied a patch, then reverted it (on perf grounds) and then nothing. New description: Over time we have evolved into a messy and bad place for the interaction of strictness analysis and exceptions. Here's the amazing history of the strictness of `catch#` * Dec 13: 0558911f91c: catch# gets a strictness signature with `lazyApply1Dmd` * Jul 15: 7c0fff41789: catch# goes from `lazyApply1Dmd` to `strictApply1Dmd` * Dec 15: 28638dfe79e: catch# goes from `strictApply1Dmd` to `lazyApply1Dmd`. Trac #10712 * Jan 16: 9915b656440: catch# goes from `lazyApply1Dmd` to `catchArgDmd`, and result goes from `botRes` to `exnRes` Trac #11222. * Mar 17: 701256df88c: catch# goes from `catchArgDmd` to `lazyApply1Dmd`. This ticket #13330. See also * The [wiki:Exceptions] page * `Note [Strictness for mask/unmask/catch]` in `primops.txt/pp`. * `exceptions_and_strictness` in `primops.txt/pp`. * `Note [Exceptions and strictness]` in `Demand.hs` * #11555, #13330, #10712, #11222 '''Item 1: ThrowsExn''' * The strictness analyser has quite a bit of complexity around `ThrowsExn`. * `ThrowsExn` only differs from `Diverges` if the `ExnStr` flag is set to `ExnStr` * And the only place that happens is in `Demand.catchArgDmd` * The only place `catchArgDmd` is used is in `primops.txt.pp`. Originally, in the patch for #11222, `catchArgDmd` was used for the first arg of `catch#`, `catchSTM#` and `catchRetry#`. * But the patch in this ticket removed two of those three; now only `catchRetry#` uses the `catchArgDmd` thing. It looks to me as if `catchRetry#` was left out by mistake; and indeed David says "I left it out on the grounds that I didn't understand it well enough." And if so, that's the last use of `catchArgDmd` and I think that all the tricky `ThrowsExn` machinery can disappear. '''Item 2: strictness of catchException''' As a result of all this to-and-fro we have in GHC.IO {{{ catch (IO io) handler = IO $ catch# io handler' catchException !io handler = catch io handler }}} That is, `catchException` is strict in the IO action itself. But Neil argues in #11555, commment:6 that this is bad because it breaks the monad laws. I believe that there is some claimed performance gain from the strictness of `catchException`, but I don't believe it exists. The perf gain was from when it had a `strictApply1Dmd`; that is, it promised to call its argument. See this note in `primops.txt.pp` {{{ -- Note [Strictness for mask/unmask/catch] -- Consider this example, which comes from GHC.IO.Handle.Internals: -- wantReadableHandle3 f ma b st -- = case ... of -- DEFAULT -> case ma of MVar a -> ... -- 0# -> maskAsynchExceptions# (\st -> case ma of MVar a -> ...) -- The outer case just decides whether to mask exceptions, but we don't want -- thereby to hide the strictness in 'ma'! Hence the use of strictApply1Dmd. }}} I think the above saga was all in pursuit of exposing the strictness of `ma` if we used `catch#` instead of `maskAsynchExceptions#` in this example. But the saga ultimate appears to have failed, and the strictenss annotation in `catchException` is a vestige that carries no benefit, but does requires comments etc. '''Item 3: performance''' If making `catch#` have strictness `strictApply1Dmd` improves perf, it would be good to know where. That would entail making the (tiny) change, recompiling all, and nofibbing. Here is the commit message in 7c0fff41789, which added `strictApply1Dmd`: {{{ commit 7c0fff41789669450b02dc1db7f5d7babba5dee6 Author: Simon Peyton Jones Date: Tue Jul 21 12:28:42 2015 +0100 Improve strictness analysis for exceptions Two things here: * For exceptions-catching primops like catch#, we know that the main argument function will be called, so we can use strictApply1Dmd, rather than lazy Changes in primops.txt.pp * When a 'case' scrutinises a I/O-performing primop, the Note [IO hack in the demand analyser] was throwing away all strictness from the code that followed. I found that this was causing quite a bit of unnecessary reboxing in the (heavily used) function GHC.IO.Handle.Internals.wantReadableHandle So this patch prevents the hack applying when the case scrutinises a primop. See the revised Note [IO hack in the demand analyser] Thse two things buy us quite a lot in programs that do a lot of IO. Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg -0.4% -2.9% -0.9% -1.0% +0.0% reverse-complem -0.4% -10.9% +10.7% +10.9% +0.0% simple -0.3% -0.0% +26.2% +26.2% +3.7% sphere -0.3% -6.3% 0.09 0.09 +0.0% -------------------------------------------------------------------------------- Min -0.7% -10.9% -4.6% -4.7% -1.7% Max -0.2% +0.0% +26.2% +26.2% +6.5% Geometric Mean -0.4% -0.3% +2.1% +2.1% +0.1% }}} If these gains are still on the table (i.e. moving to `strictApply1Dmd` gives them), perhaps we can add some strictness annotations to the I/O to replicate the effect, even if we'd decided we can't actualy make `catch#` strict? '''Item 4: IO hack in the demand analyser''' In getting up to speed with this, I noticed this comment in the demand analyser: {{{ {- Note [IO hack in the demand analyser] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's a hack here for I/O operations. Consider case foo x s of { (# s', r #) -> y } ...omitted... However, consider f x s = case getMaskingState# s of (# s, r #) -> case x of I# x2 -> ... Here it is terribly sad to make 'f' lazy in 's'. After all, getMaskingState# is not going to diverge or throw an exception! This situation actually arises in GHC.IO.Handle.Internals.wantReadableHandle (on an MVar not an Int), and made a material difference. So if the scrutinee is a primop call, we *don't* apply the state hack... }}} Idea: in the nested-CPR work, we have simple termination information. So we can use that, instead of "is a primop call" to deliver on this hack in a much more principled way. '''Item 5: raiseIO#''' There is an unresolved question about whether `raiseIO#` should return an exception result in its strictness signature. See Trac #13380, which applied a patch, then reverted it (on perf grounds) and then nothing. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 22:35:19 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 22:35:19 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.5c0428f992e3fbcac9ffeeda9dc604bc@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.10.3 Resolution: wontfix | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10712, #14998 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: > I think we can close this? Yes I think so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 22:52:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 22:52:34 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.9de7f46082981a5dc11d3d8893c8b373@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. But note that is should work for equality constraints like `(a ~ b)`, and I bet it does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 23:06:32 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 23:06:32 -0000 Subject: [GHC] #16252: QuantifiedConstraints: lack of inference really is a problem In-Reply-To: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> References: <052.0efa78aaa5c03a9a67f02be699330d8d@haskell.org> Message-ID: <067.dca64bc62693813e37e9d16a5a8b0a71@haskell.org> #16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lightandlight): Okay. Do you have any advice regarding my current issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 23:24:29 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 23:24:29 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.78b842002516c80ff9656b889de23237@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #15463 Comment: cc'ing since I'm also seeing this failure on `validate-x86_64-linux- fedora27` ([https://ghc- gitlab.s3.amazonaws.com/43/4c/434c9b5ae514646bbd91b50032ca579efec8f22bf0b4aac12e65997c418e0dd6/2019_01_31/19893/29214/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190131T232149Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190131 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=aa92a0872c8d7ee3a515f8b94b3a6a0c6aee43b9702e8718ca8508d00bc046e0 here]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 23:25:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 23:25:04 -0000 Subject: [GHC] #15463: "Serious" validation failures on i686 In-Reply-To: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> References: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> Message-ID: <063.f924329db59a3416f2787036fd1d2150@haskell.org> #15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: T3171, | heapprof001 Blocked By: | Blocking: Related Tickets: #15382, #15383 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #15383 => #15382, #15383 Comment: And the `heapprof001` failure is being tracked as #15382. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 23:34:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 23:34:12 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.e97ff0c6300f857cb63550a45204ffe2@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Why should equality constraints be accepted? In fact, we moved in the opposite direction in https://phabricator.haskell.org/D5397#149402. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 31 23:54:07 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Jan 2019 23:54:07 -0000 Subject: [GHC] #16242: Hadrian is too aggressive in rebuilding In-Reply-To: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> References: <047.3d9bf05ba201ff163bfad633a639939a@haskell.org> Message-ID: <062.3fd82ac14bbfd1c38d8232e9eeb54bbd@haskell.org> #16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): > As to whether Hadrian should emulate this, I'm torn. Certainly we should have some target for running the testsuite against an arbitrary out-of- tree GHC. However, it would make sense if hadrian test tested the current working directory. FWIW, I have implemented this as part of my work to tweak the `validate` script to support hadrian. Required several changes. I'll push a MR tomorrow I think. -- Ticket URL: GHC The Glasgow Haskell Compiler