From ghc-devs at haskell.org Sun Apr 1 00:44:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 00:44:48 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.dde958041a5cc421a8b48d436b5cafbf@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I've diagnosed the proximate cause. In the failing version of the compiler, an inplace build creates a `gmp` directory in `libraries /integer-gmp/dist-install/build/`: {{{ MacBook-Pro-97:ghc-quick1 ezyang$ ls libraries/integer-gmp/dist- install/build/ GHC gmp HSinteger-gmp-1.0.1.0.o include autogen integer-gmp.buildinfo cbits libHSinteger- gmp-1.0.1.0-ghc8.5.20180331.dylib config.log libHSinteger-gmp-1.0.1.0.a config.status }}} Unfortuantely, this changes the behavior of our print file name invocation: {{{ MacBook-Pro-97:ghc-quick1 ezyang$ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/ezyang/Dev/ghc-quick1/libraries/integer-gmp /dist-install/build --print-file-name gmp /Users/ezyang/Dev/ghc-quick1/libraries/integer-gmp/dist-install/build/gmp }}} This should return `gmp`. When it returns a file path, we attempt to open this location, which clearly will not work: {{{ *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/ezyang/Dev/ghc- quick1/libraries/integer-gmp/dist-install/build --print-file-name gmp addLibrarySearchPath: dll_path = `/Users/ezyang/Dev/ghc-quick1/libraries /integer-gmp/dist-install/build' Loading package integer-gmp-1.0.1.0 ... addDLL: dll_name = '/Users/ezyang/Dev/ghc-quick1/libraries/integer-gmp/dist-install/build /libHSinteger-gmp-1.0.1.0-ghc8.5.20180331.dylib' internal_dlopen: dll_name = '/Users/ezyang/Dev/ghc-quick1/libraries /integer-gmp/dist-install/build/libHSinteger- gmp-1.0.1.0-ghc8.5.20180331.dylib' loadArchive: start loadArchive: Loading archive `/Users/ezyang/Dev/ghc-quick1/libraries /integer-gmp/dist-install/build/gmp' ghc-stage2: loadArchive: Failed reading header from `/Users/ezyang/Dev /ghc-quick1/libraries/integer-gmp/dist-install/build/gmp' loadArchive: done *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180331 for x86_64-apple-darwin): loadArchive "/Users/ezyang/Dev/ghc-quick1/libraries/integer-gmp /dist-install/build/gmp": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I hazard some change in Cabal caused the 'gmp' directory to be created. Not entirely sure what the correct fix is yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 01:17:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 01:17:54 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.9c591179d75328940e63a5ef0abc4c70@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: angerman (added) Comment: angerman, CC'ing you, because the `gmp` folder exists in `build` because of https://github.com/haskell/cabal/pull/4874/commits I think the easiest fix we can do for now is just rename the folder we put the `config.mk` in, but we should work out a way to dodge this footgun in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 04:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 04:28:57 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.1cc7073768fdd4925a873093a58bbba8@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There's always room for simplification, of course, but I think the room here is limited. This whole mechanism came into being when `ExpType`s were introduced. `ExpType`s are "holes" -- places to write a type once we infer it; they replaced `SigmaTv` tyvars that were used previously. I forget what aspect of `ExpType`s specifically forced the rewrite of rebindable syntax, but I do remember that this was more-or-less forced. The reason for the complication is that we want to allow for the possibility that `(>>=) :: blah -> (forall x. x -> x) -> wurble`, where the arguments might have a higher-rank type. This, in turn, requires skolemization while type-checking. That problem with the current setup is that the two arguments are checked in the same `thing_inside`, where they should really be in ''different'' contexts. But that would make the whole scheme even more complicated. So I'm a bit stuck really on how you would want to simplify this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 06:08:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 06:08:14 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.159b9cb6bf9bbf04b694c1af07f4c657@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): @ezyang, right. So what we actually want is to improve the archive lookup logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 07:41:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 07:41:13 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.9cb8f82ba236572df9d1f770d940412c@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * status: new => patch * differential: => D4553 Comment: Differential that ensures we verify whatever `gcc --print-file-name` returns is actually a file, and ignore it if not. (Should ignore folders). @ezyang, thanks for the analysis! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 13:59:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 13:59:14 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.9004d83bed39dd3a1d3843da89ca462a@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: dfeuer (added) Comment: Replying to [comment:11 simonpj]: Thanks for your comments, Simon! I realized that if I apply the combine-most-common-alts optimization ''only'' in `CSE.combineAlts`, we'd get "suboptimal" results in cases like this: {{{#!hs case x of A -> 1 B -> 1 C -> 2 D -> 2 E -> 2 }}} Here, `combineIdenticalAlts` (which in my understanding runs first) would combine the `A` and `B` alts, defeating `CSE.combineAlts` which could combine `C`, `D` and `E`. I'm not sure if this warrants doing the optimization in both places with `-O2`. ------------- I also noticed that unlike `combineIdenticalAlts` `CSE.combineAlts` doesn't combine the ticks of the identical alts. Would you, David, happen to know why this is permissible in this case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 14:24:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 14:24:46 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.e107a769bfd56ac9e86686077c1605d0@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): One issue that pops up: Is it more or less useful to have the type of the expression rather than the type of the function being suggested? In this case, it would be `(-) (_ :: Integer) :: Integer -> Integer`, as specified by the type of the hole. In fact, if we show the specialized type, it would be the type of the hole in all situations, since that's what we're looking for in the first place! Right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 14:52:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 14:52:12 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.856e8ef7b01461685c046be756fc8c3c@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: D4553 => Phab:D4553 Comment: Hmm. Suppose that `gcc --print-file-name` would have printed a real file name, and instead the existence of `gmp` directory in basedir causes `gcc` to print the `gmp` in `basedir`. Wouldn't we now have lost information that `gcc --print-file-name` would have otherwise given? OTOH I guess there isn't really any way to get the correct information now (unless you remove `basedir`, I suppose) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 16:20:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 16:20:38 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.88e7623540ed8475e0b88ef2d1b7821d@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:24 George]: this seems to have regressed with 8.4.1, original test case is now using 10-11 gb on my mac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 17:08:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 17:08:57 -0000 Subject: [GHC] #14958: QuantifiedConstraints: Doesn't apply implication for existential? In-Reply-To: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> References: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> Message-ID: <066.f0cacb92dec0385ca2db16781246fc36@haskell.org> #14958: QuantifiedConstraints: Doesn't apply implication for existential? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Ah! That makes perfect sense, we can specify a `Proxy cls` and not change the kind of `Foo` although I'm not sure this gives me what I want {{{#!hs data Foo where Foo :: Proxy cls -> (forall x. ((forall y. cls y => Num y), cls x) => x) -> Foo a :: Foo a = Foo (Proxy :: Proxy Num) 10 b :: Foo b = Foo (Proxy :: Proxy Fractional) 10.0 }}} I have a draft ready for an overview of this extension from ticket:14840#comment:6, should I email it to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 17:26:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 17:26:21 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.7a65f34964b1412ad05b0f420ddb90c0@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm 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 ulysses4ever): * keywords: => llvm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 17:41:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 17:41:11 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.e6332f0a2e8a73b2e522a59347de8279@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): How does the following look (ignore the double mention of `f` in the valid substitution list)? {{{ tref.hs:4:5: error: • Found hole: _ :: [Integer] -> Integer • In the expression: _ In an equation for ‘f’: f = _ • Relevant bindings include f :: [Integer] -> Integer (bound at tref.hs:4:1) Valid substitutions include f :: [Integer] -> Integer (bound at tref.hs:4:1) main :: forall a. a (bound at tref.hs:7:1) f :: [Integer] -> Integer (defined at tref.hs:4:1) Valid refinement substitutions include foldl1 (_ :: Integer -> Integer -> Integer) where foldl1 :: forall (t :: * -> *). Data.Foldable.Foldable t => forall a. (a -> a -> a) -> t a -> a (imported from ‘Prelude’ at tref.hs:1:17-22 (and originally defined in ‘Data.Foldable’)) foldr1 (_ :: Integer -> Integer -> Integer) where foldr1 :: forall (t :: * -> *). Data.Foldable.Foldable t => forall a. (a -> a -> a) -> t a -> a (imported from ‘Prelude’ at tref.hs:1:47-52 (and originally defined in ‘Data.Foldable’)) foldl (_ :: Integer -> Integer -> Integer) (_ :: Integer) where foldl :: forall (t :: * -> *). Data.Foldable.Foldable t => forall b a. (b -> a -> b) -> b -> t a -> b (imported from ‘Prelude’ at tref.hs:1:33-37 (and originally defined in ‘Data.Foldable’)) foldr (_ :: Integer -> Integer -> Integer) (_ :: Integer) where foldr :: forall (t :: * -> *). Data.Foldable.Foldable t => forall a b. (a -> b -> b) -> b -> t a -> b (imported from ‘Prelude’ at tref.hs:1:40-44 (and originally defined in ‘Data.Foldable’)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 19:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 19:54:45 -0000 Subject: [GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds In-Reply-To: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> References: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> Message-ID: <065.2297960b5816b13bb0585cbb146bd8b6@haskell.org> #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4554 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4554 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 20:13:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 20:13:50 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.42f13616e1d50d3f54c5cce179231be0@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+---------------------------------- Comment (by varosi): I'm using compiler from https://www.haskell.org/ghc/download_ghc_8_4_1.html#linux_aarch64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 20:15:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 20:15:15 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.a37e08efd72cba882e5ae4fdd61ede73@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+---------------------------------- Comment (by varosi): It's strange that it shows me the error at run-time. May be if compiler is not built with NUMA support there should be no "--numa" option support, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 1 20:19:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Apr 2018 20:19:13 -0000 Subject: [GHC] #14981: GHC parallel GC is not doing well on modern many-core machine In-Reply-To: <045.edcae7298a9f211a21f281dc6371e306@haskell.org> References: <045.edcae7298a9f211a21f281dc6371e306@haskell.org> Message-ID: <060.d56b03ac5815a16a6da8b4cc6aed2db7@haskell.org> #14981: GHC parallel GC is not doing well on modern many-core machine -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I tried different nursery sizes. Even up to 300Mb, but the problem is that memory bandwidth has a cost and even with 128Gb of RAM, using more memory just slows down total run times/throughput. btw, I have written more on what I tried here: https://www.reddit.com/r/haskell/comments/85vwlq/our_lovely_ghc_parallel_gc_on_96_core_arm/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 02:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 02:44:08 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.6ea60bd7f5cf45186c37f24686462b44@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | 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: #13364, #14040 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"faec8d358985e5d0bf363bd96f23fe76c9e281f7/ghc" faec8d35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="faec8d358985e5d0bf363bd96f23fe76c9e281f7" Track type variable scope more carefully. The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 02:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 02:44:08 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.feeb6cf5d5ef4776f3b9efee081b230e@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 14270 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"ef443820b71f5c9c2dca362217f1a9fbab6dd736/ghc" ef443820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ef443820b71f5c9c2dca362217f1a9fbab6dd736" Apply the interim fix for #14119 to liftCoMatch Matching in the presence of casts can happen in liftCoMatch, too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 02:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 02:44:08 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.a4c05daf1a8977d0a1bf97a119486f88@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14749 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"faec8d358985e5d0bf363bd96f23fe76c9e281f7/ghc" faec8d35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="faec8d358985e5d0bf363bd96f23fe76c9e281f7" Track type variable scope more carefully. The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 02:46:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 02:46:04 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.8e69817154bd5ecc90b250de94442b15@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T14066a, | dependent/should_fail/T14066{,c,d,e,f,g,h} Blocked By: | Blocking: Related Tickets: #13364, #14040 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T14066a, dependent/should_fail/T14066{,c,d,e,f,g,h} * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 02:46:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 02:46:56 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.472c19f59a93586a17756f171d767b77@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14749 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hmm. In retrospect, I'm not sure which of these commits (which I've worked on together) actually nailed this one. But it's nailed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 03:33:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 03:33:42 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.5319261518e1fc331efe8c2e1cbb23ac@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): You ask a good question about IDE usage. I don't have a good answer there... the `Num a0` constraint is something more for the programmer to know about than to have literally in the code anywhere. As for the new output, I like it! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 08:56:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 08:56:56 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.beeb70ecc9eca1f0d5442cbc8793b7cf@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Here, combineIdenticalAlts (which in my understanding runs first) would combine the A and B alts, defeating CSE.combineAlts which could combine C, D and E. But that would introduce a nasty phase-ordering problem. Instead, maybe `CSE.combineAlts` should transform {{{ case x of DEFAULT -> 1 C -> 2 D -> 2 E -> 2 }}} (which the user might have written) into {{{ case x of DEFAULT -> 2 A -> 1 B -> 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 09:00:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 09:00:05 -0000 Subject: [GHC] #14958: QuantifiedConstraints: Doesn't apply implication for existential? In-Reply-To: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> References: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> Message-ID: <066.8162d1309fd9a0cfc4e16eae7363a5cd@haskell.org> #14958: QuantifiedConstraints: Doesn't apply implication for existential? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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 have a draft ready for an overview of this extension from ticket:14840#comment:6, should I email it to you? A draft of what? A blog post? If so, I suggest you just post it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 09:07:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 09:07:32 -0000 Subject: [GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds In-Reply-To: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> References: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> Message-ID: <065.6876b0a709c74428ef0c833993d8fcd4@haskell.org> #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4554 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks great. I've added a comment, but the new "Submit quietly" thing (which I dislike) means you may not see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 10:43:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 10:43:09 -0000 Subject: [GHC] #14968: QuantifiedConstraints: Can't be RHS of type family instances In-Reply-To: <044.8604cb7a4154bec744684958eded781f@haskell.org> References: <044.8604cb7a4154bec744684958eded781f@haskell.org> Message-ID: <059.17bb051e929b1021818b26b6e9c1ead5@haskell.org> #14968: QuantifiedConstraints: Can't be RHS of type family instances -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The challenge is knowing whether a type `(F t)` might reduce to a polytype. Currently that cannot happen. Allowing it to happen gives all the same problems as impredicativity in general. So I think that allowing a forall on the RHS of a `type instance` is a big step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 10:46:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 10:46:33 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.1a2d986cd794ab58a74b8792e757dc2b@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 14270 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm getting an unexpected pass for `typecheck/should_compile/SplitWD` which is marked as `expect_broken(14119)`. Richard, what's up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:14:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:14:14 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families In-Reply-To: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> References: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> Message-ID: <062.cea6ae17350dce1b354a8795c9b8af9f@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypedHoles 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: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:14:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:14:59 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.f7a8498e5ee4e5a74229a4552e33713e@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10267 Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:15:54 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.78641c981dbd5b3f32aabe2f4aa7ad9b@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: (none) dominiquedevriese | Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: TypedHoles 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: holes => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:16:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:16:05 -0000 Subject: [GHC] #10954: Add class/context information to typed hole relevant bindings In-Reply-To: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> References: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> Message-ID: <060.f6c8029e71e08dee4cde4422c1598768@haskell.org> #10954: Add class/context information to typed hole relevant bindings -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479, #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:17:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:17:09 -0000 Subject: [GHC] #5910: Holes with other constraints In-Reply-To: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> References: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> Message-ID: <060.2bc15267d52a06c5d3e4c02594070449@haskell.org> #5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: holes => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:17:50 -0000 Subject: [GHC] #11186: Give strong preference to type variable names in scope when reporting hole contexts In-Reply-To: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> References: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> Message-ID: <060.bd1183fd539457cdb7ffbbfb2c74f2a5@haskell.org> #11186: Give strong preference to type variable names in scope when reporting hole contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: TypedHoles 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: typed-holes => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:18:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:18:14 -0000 Subject: [GHC] #14858: Typed hole subtitution search fails in the REPL In-Reply-To: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> References: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> Message-ID: <059.7fbbd2399be2a5b892c00743387c8030@haskell.org> #14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: TypedHoles 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: typed holes substitutions => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:19:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:19:26 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.41429ffb697272ab7cde28a2645ed414@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: pallm@… (added) Comment: I think this is a variant of #14884. The machinery that Mathias Gissurarson (cc'd) has implemented for reporting typed holes, does not set type-variable level numbers properly. In that context it doesn't matter much; but it's very unsatisfactory. I recently had a long conversation with Mathias about various improvements to the type-hole-reporting mechanism. So we can expect improvements here. Here is the [wiki:Holes main wiki page about typed holes] which summarises the state of play -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:19:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:19:49 -0000 Subject: [GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking In-Reply-To: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> References: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> Message-ID: <064.13475f8ce82cd8a51080989c5562f54b@haskell.org> #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypedHoles 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: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 11:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 11:21:43 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.c23d5ea438d30675bc5a3537505cef1b@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In the end, they'll still be emitted as jumps since they're tail calls. Probably more important: for C and LLVM we can convert them into genuine loops, which the C/LLVM compiler will do a much better job of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:01:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:01:13 -0000 Subject: [GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking In-Reply-To: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> References: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> Message-ID: <064.bc841657c40c19c51ce8868f086fe9f2@haskell.org> #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypedHoles 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): My untested hunch is that my recent fix for #14066 fixed this on the way. Will test in a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:04:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:04:06 -0000 Subject: [GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking In-Reply-To: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> References: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> Message-ID: <064.f387d34cad9c4c9454099c226fa02b8f@haskell.org> #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypedHoles 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 somewhat doubt it.. the calls to the constraint solver from `TcErrors.validSubstitutions` are wonky. I discussed this with Mathias, and he is on the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:20:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:20:06 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families Message-ID: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program typechecks on GHC 8.2.2 and 8.4.1: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind type family Promote (k :: Type) :: Type type family PromoteX (a :: k) :: Promote k type family Demote (k :: Type) :: Type type family DemoteX (a :: k) :: Demote k ----- -- Type ----- type instance Demote Type = Type type instance Promote Type = Type type instance DemoteX (a :: Type) = Demote a type instance PromoteX (a :: Type) = Promote a ----- -- Arrows ----- data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type instance Demote (a ~> b) = DemoteX a -> DemoteX b type instance Promote (a -> b) = PromoteX a ~> PromoteX b }}} However, it fails to typecheck on GHC HEAD: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180401: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:34:34: error: • Expected a type, but ‘PromoteX a’ has kind ‘Promote (TYPE t0)’ • In the first argument of ‘(~>)’, namely ‘PromoteX a’ In the type ‘PromoteX a ~> PromoteX b’ In the type instance declaration for ‘Promote’ | 34 | type instance Promote (a -> b) = PromoteX a ~> PromoteX b | ^^^^^^^^^^ Bug.hs:34:48: error: • Expected a type, but ‘PromoteX b’ has kind ‘Promote (TYPE t1)’ • In the second argument of ‘(~>)’, namely ‘PromoteX b’ In the type ‘PromoteX a ~> PromoteX b’ In the type instance declaration for ‘Promote’ | 34 | type instance Promote (a -> b) = PromoteX a ~> PromoteX b | ^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:34:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:34:27 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.89ddd18750f05044c72a3193c58943c2@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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 conceivably correct behavior. In the last two lines, all we know about the kinds of `a` and `b` is that they are `TYPE r1` and `TYPE r2`. Because you don't have instances to promote/demote `TYPE`, GHC gets stuck. In function type signatures, GHC defaults `RuntimeRep`s to `LiftedRep`. Perhaps it should, also, in type family instances. I don't know why this behavior changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:43:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:43:10 -0000 Subject: [GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking In-Reply-To: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> References: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> Message-ID: <064.311167eff0d9783120822146424f3aac@haskell.org> #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypedHoles 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 Richard Eisenberg ): In [changeset:"07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb/ghc" 07abff71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb" Test #14884, #14969 These were fixed by faec8d358985e5d0bf363bd96f23fe76c9e281f7 test cases: typecheck/should_fail/T14884 ghci/scripts/T14969 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:43:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:43:10 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.075c392c750bc73bb34c519700026c8c@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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:"07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb/ghc" 07abff71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07abff7192dcc9ce667d3c5cdb3f34ca8c87f2fb" Test #14884, #14969 These were fixed by faec8d358985e5d0bf363bd96f23fe76c9e281f7 test cases: typecheck/should_fail/T14884 ghci/scripts/T14969 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:43:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:43:59 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.b9f76d5d5b5083e9816d0ea1fbdc85a4@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => ghci/scripts/T14969 * resolution: => fixed Comment: I nabbed this one by accident. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:45:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:45:07 -0000 Subject: [GHC] #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking In-Reply-To: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> References: <049.e0dc234c0a117697c411dc48fa40d3fb@haskell.org> Message-ID: <064.5cf1a7afc9c0c95818fc44ecdfbf2ebf@haskell.org> #14884: Type holes cause assertion failure in ghc-stage2 compiler during type checking -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T14884 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T14884 * status: new => closed * resolution: => fixed Comment: Yes, they were wonky. I fixed them, as they caused failures in my work on #14066. Sorry to waste Matthias's time! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 13:52:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 13:52:39 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.60e51f48367e09437e02b6aef3fd0e3d@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Yes, I've hit this recently during my work on improving the implementation of the suggestions, and now I've become more familiar with how to properly set the tcLevel. I'll submit the patch soon (hopefully), after I manage to iron out a few more kinks. Thanks for the nab goldfire, hopefully there won't be any more to nab :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 14:12:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 14:12:48 -0000 Subject: [GHC] #14958: QuantifiedConstraints: Doesn't apply implication for existential? In-Reply-To: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> References: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> Message-ID: <066.77303f618ce4757592fc801e4b4110cd@haskell.org> #14958: QuantifiedConstraints: Doesn't apply implication for existential? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Ah I started writing it as a paper -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 14:26:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 14:26:08 -0000 Subject: [GHC] #14968: QuantifiedConstraints: Can't be RHS of type family instances In-Reply-To: <044.8604cb7a4154bec744684958eded781f@haskell.org> References: <044.8604cb7a4154bec744684958eded781f@haskell.org> Message-ID: <059.d73e530895b2d110740f1d7e8d3edc08@haskell.org> #14968: QuantifiedConstraints: Can't be RHS of type family instances -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This compiles {{{#!hs type family Functors (fs :: [(Type -> Type) -> Type -> Type]) :: Constraint type instance Functors '[] = (() :: Constraint) type instance Functors (t:ts) = (LvlUp Functor t, Functors ts) class (forall x. cls x => cls (f x)) => LvlUp cls f instance (forall x. cls x => cls (f x)) => LvlUp cls f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 14:30:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 14:30:07 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.a5547d0e30bee8fd395390a1d9356503@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556 Wiki Page: | -----------------------------------+---------------------------------- Changes (by bgamari): * status: infoneeded => patch * differential: => Phab:D4556 Comment: Perhaps Phab:D4556 will help things in this area a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 14:34:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 14:34:31 -0000 Subject: [GHC] #14968: QuantifiedConstraints: Can't be RHS of type family instances In-Reply-To: <044.8604cb7a4154bec744684958eded781f@haskell.org> References: <044.8604cb7a4154bec744684958eded781f@haskell.org> Message-ID: <059.35eb1cb2c7a0bd62b79ff90e3e68de6d@haskell.org> #14968: QuantifiedConstraints: Can't be RHS of type family instances -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: QuantifiedConstraints => QuantifiedConstraints wipT2893 Comment: Relevant discussion at ticket:14734#comment:5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 15:20:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 15:20:05 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.10177a6c0813174991cce3f3afe2cc82@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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): Commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`) is responsible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 15:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 15:34:54 -0000 Subject: [GHC] #14958: QuantifiedConstraints: Doesn't apply implication for existential? In-Reply-To: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> References: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> Message-ID: <066.96e51295bf64891c031f4c297ea518af@haskell.org> #14958: QuantifiedConstraints: Doesn't apply implication for existential? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Even better! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 15:36:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 15:36:35 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.d0271c5f02025e6a9a6d440e9be814a0@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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 simonpj): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 15:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 15:37:43 -0000 Subject: [GHC] #14968: QuantifiedConstraints: Can't be RHS of type family instances In-Reply-To: <044.8604cb7a4154bec744684958eded781f@haskell.org> References: <044.8604cb7a4154bec744684958eded781f@haskell.org> Message-ID: <059.3b291df38fbb566b2f3b3d44ed0ae318@haskell.org> #14968: QuantifiedConstraints: Can't be RHS of type family instances -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well comment:9 doesn't have foralls on the RHS of a type family, so should be fine. I'm not sure how/why it's relevant to this thread though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 15:42:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 15:42:06 -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.1f01c8a1fdf660f1f40d74f8635da578@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: wontfix | QuantifiedConstraints wipT2893 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 Iceland_jack): Replying to [comment:11 RyanGlScott]: I don't think you need quantified constraints (the ticket:14822#comment:3 trick does works to solve my previous comment), how about this: {{{#!hs instance Typeable f => Show (ExTyFam f) where show (MkExTyFam x) | Just HRefl <- typeRep @f `eqTypeRep` typeRep @(Proxy :: Type -> Type) = show x | otherwise = .. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:04:44 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.43c3f95b35fcc50d40e5716e8bde5f44@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9187d5fb1d3d38a4e607b0d61784c21447c8195b/ghc" 9187d5fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9187d5fb1d3d38a4e607b0d61784c21447c8195b" Allow unpacking of single-data-con GADTs Trac #14978 pointed out that single-constructor GADTs should be unpackable without trouble. Acutally I realise that even existentials should be unpackable too, but that's a bit more work, so it's not part of this patch. See Note [Unpacking GADTs and existentials] in MkId. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:04:44 -0000 Subject: [GHC] #14936: GHC 8.4 performance regressions when using newtypes In-Reply-To: <046.51c083465a95f77099b97377aa2723e3@haskell.org> References: <046.51c083465a95f77099b97377aa2723e3@haskell.org> Message-ID: <061.9e716db23f23cc9375f6163f581d81bc@haskell.org> #14936: GHC 8.4 performance regressions when using newtypes -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5ab8094e4579c08973260c2d18599be0738526ec/ghc" 5ab8094/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5ab8094e4579c08973260c2d18599be0738526ec" SpecConstr: accommodate casts in value arguments This commit: commit fb050a330ad202c1eb43038dc18cca2a5be26f4a Author: Simon Peyton Jones Date: Thu Oct 12 11:00:19 2017 +0100 Do not bind coercion variables in SpecConstr rules arranged to reject any SpecConstr call pattern that mentioned a coercion in the pattern. There was a good reason for that -- see Note [SpecConstr and casts] -- but I didn't realise how important it was to accept patterns that mention casts in /terms/. Trac #14936 showed this up. This patch just narrows the restriction to discard only the cases where the coercion is mentioned only in types. Fortunately that was pretty easy to do. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:05:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:05:37 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.2e2612d68ac0ac498ec8514853339b3e@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T14978 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T14978 Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:08:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:08:22 -0000 Subject: [GHC] #14992: Allow existentials to UNPACK Message-ID: <046.2628d1f5bc20d2bff69c94dab08922e2@haskell.org> #14992: Allow existentials to UNPACK -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider {{{ data T a where MkT :: b -> (b->a) -> T a data Wuggle where MkW :: {-# UNPACK #-} !T Int -> Wuggle }}} Here `MkT` has an existential, but there is really no reason that it can't unpack into the data constructor for `MkW`. But it is currently rejected. Fixing this would require quite a bit of new plumbing. E.g. the existential type variable of the worker and wrapper would differ, which is not true today. But morally it's the Right Thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:10:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:10:21 -0000 Subject: [GHC] #10016: UNPACK support for existentials In-Reply-To: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> References: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> Message-ID: <061.b1aa6a8366f6396d471bf7a0c334bf88@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: DataCons 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: => DataCons Old description: > Consider > {{{ > data Foo = forall a. Show a => Foo !a !a > > data Bar = Bar {-# UNPACK #-} !Foo > }}} > The UNPACK pragma should really be able to unpack the `Foo` field, so > that (implementation-wise) it would be as if you'd declared `Bar` thus: > {{{ > data Bar = forall a. Show a => Bar !a !a > }}} > But currently we get > {{{ > Ignoring unusable UNPACK pragma on the first argument of ‘Bar’ > }}} > Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- > haskell-users/2015-January/025590.html here]. > > Vaguely related tickets: #7647, #9214. But unlike those ones, this one > looks quite feasible to me. New description: Consider {{{ data Foo = forall a. Show a => Foo !a !a data Bar = Bar {-# UNPACK #-} !Foo }}} The UNPACK pragma should really be able to unpack the `Foo` field, so that (implementation-wise) it would be as if you'd declared `Bar` thus: {{{ data Bar = forall a. Show a => Bar !a !a }}} But currently we get {{{ Ignoring unusable UNPACK pragma on the first argument of ‘Bar’ }}} Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- haskell-users/2015-January/025590.html here]. Vaguely related tickets: #7647, #9214. But unlike those ones, this one looks quite feasible to me. Fixing this would require quite a bit of new plumbing. E.g. the existential type variable of the worker and wrapper would differ, which is not true today. But morally it's the Right Thing. I'd be interested in actual use-cases. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:10:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:10:35 -0000 Subject: [GHC] #14992: Allow existentials to UNPACK In-Reply-To: <046.2628d1f5bc20d2bff69c94dab08922e2@haskell.org> References: <046.2628d1f5bc20d2bff69c94dab08922e2@haskell.org> Message-ID: <061.f2bf15f6578f2f46d24c2a63069e9b3a@haskell.org> #14992: Allow existentials to UNPACK -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Old description: > Consider > {{{ > data T a where > MkT :: b -> (b->a) -> T a > > data Wuggle where > MkW :: {-# UNPACK #-} !T Int -> Wuggle > }}} > Here `MkT` has an existential, but there is really no reason that it > can't unpack into the data constructor for `MkW`. But it is currently > rejected. > > Fixing this would require quite a bit of new plumbing. E.g. the > existential type variable of the worker and wrapper would differ, which > is not true today. But morally it's the Right Thing. New description: Consider {{{ data T a where MkT :: b -> (b->a) -> T a data Wuggle where MkW :: {-# UNPACK #-} !T Int -> Wuggle }}} Here `MkT` has an existential, but there is really no reason that it can't unpack into the data constructor for `MkW`. But it is currently rejected. -- Comment: Ugh. Duplicate of #10016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:11:18 -0000 Subject: [GHC] #14936: GHC 8.4 performance regressions when using newtypes In-Reply-To: <046.51c083465a95f77099b97377aa2723e3@haskell.org> References: <046.51c083465a95f77099b97377aa2723e3@haskell.org> Message-ID: <061.f2746cbf9012bafa3e31d65f92aa312a@haskell.org> #14936: GHC 8.4 performance regressions when using newtypes -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/should_run/T14936 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => perf/should_run/T14936 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:12:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:12:04 -0000 Subject: [GHC] #14936: GHC 8.4 performance regressions when using newtypes In-Reply-To: <046.51c083465a95f77099b97377aa2723e3@haskell.org> References: <046.51c083465a95f77099b97377aa2723e3@haskell.org> Message-ID: <061.a0cff2568191ffeda35f8c6e59e0515d@haskell.org> #14936: GHC 8.4 performance regressions when using newtypes -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/should_run/T14936 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge Comment: I'll optimistically mark this as "merge", since this seems like an important performance win. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:16:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:16:23 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.a754c554b3c5b1283b01bc6b5745bd3c@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T14978 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:16:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:16:57 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.f017836120a68ad5f241a3880d659efc@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T14978 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Do we want a new ticket to track existentials? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:32:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:32:00 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.c442211e133fa9263ffa3a4b4270042b@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T14978 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Do we want a new ticket to track existentials? It's #10016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 16:41:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 16:41:25 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.e150f1d61caa8b5a3130ab760173552b@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 17:11:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 17:11:49 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types Message-ID: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is not a bug but I am trying to understand the ~~implication~~ significance of `-XQuantifiedConstraints`. [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- outsidein.pdf OutsideIn(X)] (section **2.4**) tells us `test` actually has a principle type when we have implication constraints) {{{#!hs data T :: Type -> Type where T1 :: Int -> T Bool T2 :: T a test :: (a~Bool => b~Bool) => T a -> b -> b test (T1 n) _ = n > 0 test T2 r = r }}} that subsumes {{{#!hs test1 :: T a -> a -> a test1 = test test2 :: T a -> Bool -> Bool test2 = test }}} Now that we have `-XQuantifiedConstraints` does this change the story at all, if not you can close this.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 17:28:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 17:28:17 -0000 Subject: [GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent Message-ID: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> #14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.4.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: -------------------------------------+------------------------------------- While trying to adapt `hint` for ghc 8.4.1, I've encountered the following phenomenon where an extra `load LoadAllTargets` line causes errors. {{{#!hs -- warning: the code below creates files A.hs and B.hs in the current working directory import System.Directory import Control.Monad.IO.Class import GHCi.RemoteTypes import GHC.Paths -- cf. the ghc-paths package import Unsafe.Coerce main = do writeFile "A.hs" "module Ahidden(a) where { a :: Int; a = 42 }" let mod_nameA = mkModuleName "Ahidden" mod_targetA = Target (TargetFile "A.hs" Nothing) False Nothing runGhc (Just libdir) $ do -- setup df0 <- getSessionDynFlags (df1, _, _) <- parseDynamicFlags df0 [] setSessionDynFlags df1{ ghcMode = CompManager, hscTarget = HscInterpreted, ghcLink = LinkInMemory, verbosity = 0 } -- context : *X setTargets [mod_targetA] load LoadAllTargets load LoadAllTargets -- this line causes the next line to fail setContext [IIModule mod_nameA] -- error: -- ...: Could not find module ‘Ahidden’ -- Use -v to see a list of the files searched for. runIOExpr "print a :: IO ()" runIOExpr e = do HValue h <- compileExpr e liftIO (unsafeCoerce h :: IO ()) }}} This code works with ghc 8.2. The new behavior probably originates in 1893ba12fe1fa2ade35a62c336594afcd569736e, which adds flushing of the finder cache (main/Finder.hs) for every dependency analysis; my guess is that this is where the connection between the module name `Ahidden` and the file `A.hs` used be tracked. http://lpaste.net/364298 is a less artificial example of the same behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 17:31:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 17:31:42 -0000 Subject: [GHC] #14995: QuantifiedConstraints: Incorrect pretty printing Message-ID: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> #14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code from [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/jfp-outsidein.pdf OutsideIn(X)] compiles {{{#!hs {-# Language FlexibleInstances, MultiParamTypeClasses, GADTs, QuantifiedConstraints #-} class C a class B a b where op :: a -> b instance C a => B a [a] where op = undefined data R a where MkR :: C a => a -> R a k :: (C a => B a b) => R a -> b k (MkR x) = op x }}} but pretty-printing `k` prints `B a b => ..` instead of `(C a => B a b) => ..` {{{ $ ghci -ignore-dot-ghci Test.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/228-bug.hs, interpreted ) Ok, one module loaded. *Main> :t k k :: B a b => R a -> b *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 17:35:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 17:35:26 -0000 Subject: [GHC] #14995: QuantifiedConstraints: Incorrect pretty printing In-Reply-To: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> References: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> Message-ID: <066.cd2f5d22008a383a7586ab2622139181@haskell.org> #14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This code from [https://www.microsoft.com/en-us/research/wp- > content/uploads/2016/02/jfp-outsidein.pdf OutsideIn(X)] compiles > > {{{#!hs > {-# Language FlexibleInstances, MultiParamTypeClasses, GADTs, > QuantifiedConstraints #-} > > class C a > class B a b where op :: a -> b > instance C a => B a [a] where op = undefined > > data R a where > MkR :: C a => a -> R a > > k :: (C a => B a b) => R a -> b > k (MkR x) = op x > }}} > > but pretty-printing `k` prints `B a b => ..` instead of `(C a => B a b) > => ..` > > {{{ > $ ghci -ignore-dot-ghci Test.hs > GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( hs/228-bug.hs, interpreted ) > Ok, one module loaded. > *Main> :t k > k :: B a b => R a -> b > *Main> > }}} New description: This code from [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/jfp-outsidein.pdf OutsideIn(X)] compiles {{{#!hs {-# Language FlexibleInstances, MultiParamTypeClasses, GADTs, QuantifiedConstraints #-} class C a class B a b where op :: a -> b instance C a => B a [a] where op = undefined data R a where MkR :: C a => a -> R a k :: (C a => B a b) => R a -> b k (MkR x) = op x }}} but pretty-printing `k` prints `B a b => ..` instead of `(C a => B a b) => ..` {{{ $ ghci -ignore-dot-ghci hs/228-bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/228-bug.hs, interpreted ) Ok, one module loaded. *Main> :t k k :: B a b => R a -> b *Main> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 17:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 17:56:58 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.3146973e79a9ecc2fb096b4ca93b929a@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Namely does this comment still hold > We have ourselves flirted with quantifying over (implication) constraint schemes, but we will argue in 4.2 that this is not practical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 18:10:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 18:10:33 -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.ccb2501759e4f62629c09465f959b4ac@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: wontfix | QuantifiedConstraints wipT2893 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 Iceland_jack): An example, from [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/jfp-outsidein.pdf OutsideIn(X)] (**2.4**), this function {{{#!hs h :: forall a. (forall b. FB a b ~ Bool) => Bar a -> Bool }}} Details in [https://gist.github.com/Icelandjack/aeda8e98214cc52c96230af7b8724d25 gist]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 18:31:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 18:31:55 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.6b4fc42344404909e86ebf6ad395037a@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556 Wiki Page: | -----------------------------------+---------------------------------- Comment (by varosi): So you think that GHC compiler on haskell.org for Aarch64 is built without NUMA support? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 18:44:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 18:44:50 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.8f829d1c791f65744f773ff5854b857b@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 14270 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The commit in comment:17 fixed that, and I suppose I missed updating the test case. Fixed now (I've committed the update.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 18:50:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 18:50:45 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.e3b23cee442ba1e00688a481c2267bfa@haskell.org> #9173: Better type 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => high * owner: (none) => goldfire Comment: Some messages were worsened by the patch for #14066 that makes this a higher priority. I don't think it will be hard to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 19:11:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 19:11:00 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.5fd454ac7eb91ea690afc07c1516d48a@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): After a long discussion of design possibilities, Simon and I came to the following: 1. The current design is broken, as described in this ticket. 2. If we want to handle all rebindable syntax in a general fashion, we were unable to come up with anything simpler than the "impenetrable" code that exists. And, indeed, to fix the current flaw would likely require adding `HList`s or some such, making it even worse. 3. Much of the current complication comes from the handling of `>>=`, which has an intricate type. Specifically, we need `(>>=) :: ty1 -> (ty2 -> ty3) -> ty4`. However, it would also be quite cool if something like `(>>=) :: ty1 -> (forall a. ty2 -> ty3) -> ty4` were allowed. This effectively means that a `<-` operator in a `do` could bind an existential variable without using a pattern-match. And, if the user wrote `(>>=)` literally (without `do`), then this would indeed be possible. So it would be nice. The complication specifically stems from the fact that the code processing `BindStmt`s needs to know `ty2` and `ty3`, so we must decompose the type of `(>>=)`'s second argument. In order to do this, we need to skolemize any `forall`d variables, and skolemization requires an implication constraint, causing the bug in this ticket. 4. Rebindable syntax that decomposes list constructors suffers a similar fate, but that's not nearly as painful as `(>>=)`. Though I'm still not fully convinced, we resolved to make the treatment of rebindable syntax simpler and less general. Specifically: a. Reduce `SyntaxOpType` to have two constructors: `SynAny :: SyntaxOpType` and `SynType :: ExpType -> SyntaxOpType`. b. Make new functions `tcBindOp`, `tcFromListOp`, and `tcFromListNOp` that handle the special cases for `(>>=)` and the list functions. These won't use general mechanisms, but just be a bit repetitive with `tcSyntaxOp`. c. The `SynRho` case of `tcSyntaxOp` will be dropped. Instead, clients of `tcSyntaxOp` that need rho-types will arrange to instantiate/skolemize the sigma-types that `tcSyntaxOp` provides as needed. This will duplicate code, but it means that `tcSyntaxOp` no longer needs to be written in CPS style. It will also allow this ticket to be resolved. d. This still won't handle cases like `fromListN :: (forall a. Int) -> [b] -> c`, where one parameter of a bit of rebindable syntax has a known type, but that known type might be redundantly quantified. Handling such a case would require CPSing again, and so we won't. This means that rebindable syntax will be a bit less expressive than the manual has heretofore promised. But the only lost cases are surely of the form above, where there is an unused quantified type variable. We can arrange for a suitable error message in these cases. This change will require a user manual update. e. When all this is done, the extra flexibility in the `SyntaxExpr` type -- with its argument wrappers and result wrapper -- won't be needed. Instead, `tcSyntaxOp` can return a plain old `HsExpr`, suitably wrapped. Accommodations will have to be made in `BindStmt` and the places where list operators might crop up to store extra `HsWrapper`s to be applied to arguments. f. A Note will be placed near `tcSyntaxOp` and the bind/list functions describing this design plan. If, in the future, we want more rebindable syntax, it might encourage us to re-adopt the more general -- but more complicated -- scheme currently in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 19:28:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 19:28:00 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.19504963355b090c6902dd0598bbe4ad@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556 Wiki Page: | -----------------------------------+---------------------------------- Comment (by bgamari): Replying to [comment:8 varosi]: > So you think that GHC compiler on haskell.org for Aarch64 is built without NUMA support? I'm quite certain that it was. Currently none of the haskell.org binary distributions include NUMA support since this would require that users install `libnuma`, which isn't included in most distributions' default package sets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 19:34:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 19:34:13 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.78f8abaaaa6bad0e7d020d6d33321228@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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): I figured this one out. It turns out that `solveEqualities` needs to use `simpl_top`. In my recent patch, I thought I could get away with `solveWanteds`, and no test cases told me I couldn't. Easy enough to fix. Validating now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:25:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:25:08 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.9445d63a3fb29ff244346f97032536be@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d8d4266bf73790f65b223ec16f645763eaed8be3/ghc" d8d4266b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8d4266bf73790f65b223ec16f645763eaed8be3" Fix #14991. It turns out that solveEqualities really does need to use simpl_top. I thought that solveWanteds would be enough, and no existing test case showed up the different. #14991 shows that we need simpl_top. Easy enough to fix. test case: dependent/should_compile/T14991 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:27:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:27:33 -0000 Subject: [GHC] #14991: GHC HEAD regression involving TYPEs in type families In-Reply-To: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> References: <050.8a6e261c83aba329e777d54165bf4fb0@haskell.org> Message-ID: <065.5831a5c2beac4f52b42a5190fa958bbd@haskell.org> #14991: GHC HEAD regression involving TYPEs in type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T14991 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => dependent/should_compile/T14991 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:28:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:28:07 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.64b1fff5ba3634403b17d10fad1ce288@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): This is just a peanut-gallery comment, so forgive the naivety, but my impression is that Idris treats `do` desugaring purely syntactically, so e.g. you don't even need a Monad class or the expected types, just something called (>>=) and pure in scope. Idris of course does a lot of things fundamentally differently, not the least of which is type-directed name overloading, but that seems orthogonal. What's the problem with treating `do` as a syntax macro before even getting to typechecking? I gather the problem above is all rebindable syntax not just `do` and (>>=), but it made me curious about that one thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:29:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:29:53 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.49c5b4d0779692f67df9b80a8808145e@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually proposed doing exactly that when working this out with Simon. The problem is that doing so would ruin error messages, because we could report errors only with respect to the expanded syntax, instead of what the user actually wrote. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:32:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:32:15 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.79aa88e9b60c52d8fcc67abf9f5d55e2@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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 principle yes, but in the `wip/T2893` branch: * I deliberately never ''infer' a type with quantified constraints. It seems too easy to infer an elaborate, incomprehensible, and perhaps even insoluble, constraint when all that happened was a simple error on the programmer's part. * The design deliberately has `cls tys` or `tyvar tys` after the `=>` of a quantified constraint; not `a ~ Bool`. There are too many other ways to solve equalities! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 21:57:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 21:57:11 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.fc55f50d8772d708f19a06d9e2a30507@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by voanhduy1512): Replying to [comment:9 bgamari]: > Thanks again for picking this up! Replying to [comment:10 MikolajKonarski]: > Indeed, thank you, voanhduy1512. You are welcome. I have one more question: currently `-Wall` written in the form that's list warning that are not enable. But the code itself actually is `-W` plus few more warnings. So with more warning add to ghc, the doc will be very easy to be incorrect. Should we can the doc for -Wall to say what it included instead of excluded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 22:00:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 22:00:54 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.0ffbb5cfb30c772563774d2336c05775@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): Yeah, macros in general would need to store the original form and somehow get back to it for errors. I'm sure this has been thought about quite a bit over the decades and the devil is in that "somehow." I don't know anything about that previous work, so I'll leave it at that :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 22:34:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 22:34:17 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.dcfbc1029aa61d0c11f481aaa74574a3@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType, TypeFamilies, PartialTypeSignatures => TypeInType, TypeFamilies, PartialTypeSignatures, TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 22:44:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 22:44:31 -0000 Subject: [GHC] #14897: QuantifiedConstraints: Can't print type of quantified constraint In-Reply-To: <051.b509630009c40df070f071bb7f5dfd8f@haskell.org> References: <051.b509630009c40df070f071bb7f5dfd8f@haskell.org> Message-ID: <066.1d2c5dfe30a7055e81b2ebc4e80cbefc@haskell.org> #14897: QuantifiedConstraints: Can't print type of quantified constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints, wipT2893 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): * status: new => closed * resolution: => invalid Comment: What `:t e` does is to infer the type of the expression `e` and print it. So with `a :: (forall xx. Monoid (f xx)) => f a`, it's as if you'd typed the top level decl {{{ foo = a }}} What happens? We instantiate the type of `a` to get a Wanted constraint {{{ [W] forall x. Monoid (f1 x) }}} and the type `f1 a1`, where `f1` and `a1` are unification variables. Now we try to simplify the constraints and infer the most general type for `foo`. Unsurprisingly, we fail with the reported error message. If, rather than inferring the type of an arbitrary ''expression'', you want to ask for the type (and other info) about an ''identifier'', use `:info a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 2 22:52:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Apr 2018 22:52:17 -0000 Subject: [GHC] #14995: QuantifiedConstraints: Incorrect pretty printing In-Reply-To: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> References: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> Message-ID: <066.45ebd5b55015afc15de33fdf1e2f0daf@haskell.org> #14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 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): This is like #14897. It'l be fine if you say `:info k`. But with `:t k` you are asking GHC to infer the type of the expression `k`. So it instantiates `k` to get the constraint {{{ [W] ((C a1 => B a1 b1)) -- A quantified constraint }}} As usual `a1` and `b1` are unification variables. To solve a quantified constraint we create an implication constraint {{{ forall {}. C a1 => [W] B a1 b1 }}} Now we are stuck, so we try to generalise. GHC tries to find a simple constraint to generalise over, and `B a1 b1` does the job. GHC ''never'' infers a quantified constraint. So `:t` will never display a quantified constraint. I don't know whether others trip over this `:type` vs `:info` distinction, but you certainly do! Maybe `:type` should work only on identifiers, and be identical to `:info`. We could have something else for arbitrary expressions. Or maybe `:type` should behave non-uniformly for identifiers. Opinions welcome. But as it stands it's by-design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 01:11:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 01:11:33 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.8394bb2caf41415cc9e6b45a5aa2830f@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Aha! I'd forgotten OutsideIn(X) entertains implication constraints. If you're looking for explanation/documentation, section **4.2.1** (starting "costs to the programmer", "costs to the type inference engine") explain the rationale, and it still stands. Simon's saying quantified constraints must be explicitly given by a signature, never inferred. That's in line with many exotic type system features; and makes perfect sense. Would be worth testing the examples from section **2.4** by giving an explicit signature same as what the paper says would be inferred. Does that get `-XQuantifiedConstraints` to accept them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 03:28:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 03:28:55 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.a883fda54125183c7fdc2e84bbc1a0f8@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): It accepts them all (type family example needs some cleverness) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 07:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 07:51:12 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.a12dc08c2fb0215f50140b4b4f357e0f@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 07:59:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 07:59:30 -0000 Subject: [GHC] #14662: Partial type signatures + mutual recursion = confusion In-Reply-To: <047.3b31857d5e13c83eb10eb7b983365dfd@haskell.org> References: <047.3b31857d5e13c83eb10eb7b983365dfd@haskell.org> Message-ID: <062.6e89abe2008f15502f199cfcafe703cb@haskell.org> #14662: Partial type signatures + mutual recursion = confusion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 Tue Apr 3 07:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 07:59:53 -0000 Subject: [GHC] #14658: 'Fix two more bugs in partial signatures' broke T10846 In-Reply-To: <046.d589819107037d6543f2809768319041@haskell.org> References: <046.d589819107037d6543f2809768319041@haskell.org> Message-ID: <061.24d984cf1687bdc1366c6c568581d042@haskell.org> #14658: 'Fix two more bugs in partial signatures' broke T10846 -------------------------------------+------------------------------------- Reporter: niteria | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | 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 Tue Apr 3 08:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 08:00:02 -0000 Subject: [GHC] #14643: Partial type signatures in class constraints behave unexpectedly In-Reply-To: <047.6762d95c975e1952f57776fe89e6e2c0@haskell.org> References: <047.6762d95c975e1952f57776fe89e6e2c0@haskell.org> Message-ID: <062.4291197a5a1ad1c033f344d6e942b4e2@haskell.org> #14643: Partial type signatures in class constraints behave unexpectedly -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_compile/T14643, T14643a 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 Tue Apr 3 08:02:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 08:02:21 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.fc667cf9c2fdb8e1262240b2d19736d7@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PartialTypeSignatures 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): * keywords: => PartialTypeSignatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 08:05:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 08:05:55 -0000 Subject: [GHC] #14996: Typed holes are very slow Message-ID: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If you type at the GHCi prompt {{{ ghci> 3 _ 4 }}} (which I did for #14969), you get a multi-second pause before the error message comes out. I think this is because the error-message generator is looking through the entire type environment. But it's really too slow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 08:06:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 08:06:11 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.0d0551bfd3530bd61aff8354727d1363@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypedHoles 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: => TypedHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 08:08:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 08:08:41 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.cedcec4973e41a5e2c078d54e8118b67@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I'm not sure, because many of the new warnings are added with the intention of adding them to -Wall sooner or later, so the positive list would need to grow, too. Also, the list of warnings included in -Wall is much longer than the list of warnings excluded. An option is to provide both lists and remark that if a warning is on neither list, it must be a new one and please file a Trac ticket. Then we are at least not stating a falsehood. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 10:59:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 10:59:57 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.1c0ad70a6aad62d26a7da007b7769f39@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:10 simonpj]: > Try getting rid of the first equation for `puchCoTyArg` > {{{ > pushCoTyArg co ty > | tyL `eqType` tyR > = Just (ty, mkRepReflCo (piResultTy tyR ty)) > }}} > This is another big pile of type-equalities, rather like calling `isReflexiveCo` at the wrong moment. > > Claim: if it happens that `tyL` = `tyR`, but we go ahead with all that `mkCoherenceLeftCo` stuff anyway, then the coercion optimiser will get rid of it later. '''Richard''': will it? > > But try that change anyway. NO WAY should `pushCoTyArg` take 54% of compile time! Plain out removing that case branch gets us down by another 4 seconds: {{{ Tue Apr 3 11:09 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/tobias/well- typed/devel/ghc/T14737/inplace/lib ./cases/Grammar.hs -o ./a -fforce- recomp total time = 7.86 secs (7864 ticks @ 1000 us, 1 processor) total alloc = 10,150,661,432 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc mkInstCo CoreOpt compiler/coreSyn/CoreOpt.hs:982:33-84 31.7 40.6 tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(494,4)-(556,7) 20.6 20.4 CoreTidy HscMain compiler/main/HscMain.hs:1253:27-67 7.2 5.5 SimplTopBinds SimplCore compiler/simplCore/SimplCore.hs:770:39-74 6.6 4.6 simplCast Simplify compiler/simplCore/Simplify.hs:(1213,5)-(1215,37) 3.7 3.5 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(445,16)-(446,43) 3.5 3.1 deSugar HscMain compiler/main/HscMain.hs:511:7-44 2.4 1.9 coercionKind Coercion compiler/types/Coercion.hs:1716:3-7 1.9 4.6 isReflexiveCo Simplify compiler/simplCore/Simplify.hs:1260:40-55 1.8 1.4 Parser HscMain compiler/main/HscMain.hs:(316,5)-(384,20) 1.8 2.3 StgCmm HscMain compiler/main/HscMain.hs:(1428,13)-(1429,62) 1.6 0.7 }}} I've added a few more SCC's to trace more deeply into `simplCast`, which is why `simplCast` itself has seemingly dropped to 3.7% - this isn't accurate, because `mkInstCo` makes up most of the rest of the `simplCast` call. So I suggest committing the branch deletion (assuming that it won't break anything). From here, I'm not 100% sure which is more promising: digging into `mkInstCo` to see if we can make it more efficient, or looking at `simplCast` to see if we can make it call `mkInstCo` less often. Also: > Note that ​Phab:D4395 currently removes the piResultTy from that case, but it's quite possible that the eqType call is what's taking up the time. The full profile from before the deletion (which, unfortunately, I no longer have around) clearly shows that `eqType` is what consumes all that time, not `piResultTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 11:11:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 11:11:20 -0000 Subject: [GHC] #10016: UNPACK support for existentials In-Reply-To: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> References: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> Message-ID: <061.ff82b12ef46f1994e082842533e161e1@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: DataCons Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): As far as I can tell, the only time this feature would be ''essential'' would be a situation where you want to unpack an existential and don't have access to its constructor. That makes the "killer app" a bit tricky to find. On the other hand, it would certainly support the sum-of-records pattern: {{{#!hs data Foo = This | That !Bar data Bar = Bar { ... } }}} This lets people use named fields in sum types without introducing partial functions. As it is, it won't be efficient if `Bar` has any existentials. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 11:12:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 11:12:27 -0000 Subject: [GHC] #10016: UNPACK support for existentials In-Reply-To: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> References: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> Message-ID: <061.941471fa2ae1fe6efe4ada16a22a5d7d@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: DataCons Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 11:29:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 11:29:06 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.5811a5f35611be65bfcdf09d882cea02@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, delete the `eqType` branches in both `pushCoTyArg` and `pushValArg`. Leave a Note to say "don't do `eqType` here! (see Trac #14737)". On to `mkInstCo`. I see that it does an inefficient single-variable substitution. So if we have {{{ mkInstCo (mkInstCo (mkInstCo co (Refl t1)) (Refl t2)) (Refl t3) }}} we will traverse `co` three times (and `t1` twice etc). Bad bad. Idea: leave that to the coercion optimiser. Try simply removing the first equation for `mkInstCo` leaving {{{ mkInstCo = InstCo }}} '''Richard''': I think that the coercion optimiser will do a good job here, right? But I do see this in the `InstCo` case of `opt_co4`: {{{ -- See if it is a forall after optimization -- If so, do an inefficient one-variable substitution, then re- optimize }}} Are you sure that's a good idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 12:29:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 12:29:18 -0000 Subject: [GHC] #14997: mut_list_size calculation is off Message-ID: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> #14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Program: {{{ main = print (foldr (+) 0 [ 0 .. 10000 ] :: Int) }}} Compile: {{{ $ ghc-stage2 Main.hs -debug -rtsopts -O0 }}} Run: {{{ $ ./Main +RTS -Dg }}} It prints something like {{{ mut_list_size: 16 (0 vars, 0 arrays, 0 MVARs, 0 TVARs, 0 TVAR_WATCH_QUEUEs, 0 TREC_CHUNKs, 0 TREC_HEADERs, 0 ATOMIC_INVARIANTs, 0 INVARIANT_CHECK_QUEUEs, 0 others) }}} So there are two objects in the mut list, but `scavenge_mutable_list` wasn't able to find anything. This is curious, and it seems like a bug. Pretty much any program has this bug, `mut_list_size` and sum of objects found in the mut list never match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 12:30:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 12:30:14 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.c9f3f61262920f821866c487972729a1@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:13 simonpj]: > On to `mkInstCo`. I see that it does an inefficient single-variable substitution. So if we have > {{{ > mkInstCo (mkInstCo (mkInstCo co (Refl t1)) > (Refl t2)) > (Refl t3) > }}} > we will traverse `co` three times (and `t1` twice etc). Bad bad. > > Idea: leave that to the coercion optimiser. Try simply removing the first equation for `mkInstCo` leaving > {{{ > mkInstCo = InstCo > }}} That doesn't seem to work well at all - I don't know how long exactly it takes, but it's been compiling Grammar.hs for about half an hour now, so I think it's safe to say that it's much slower now than the 8 seconds we got previously. Unfortunately it's still running, so I can't say where the time is going yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 14:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 14:14:45 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.bf632ee7b1cb1523afd758966941af4c@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Interestingly, the coercion optimizer will '''not''' work on `InstCo ... (Refl ...)`. Other points of interest here: - The first line of the `opt_co4` case for `InstCo` looks plain wrong, extending the substitution with a use of `kind_co`, where `kind_co` has not, itself, been substituted. - `opt_co4` uses `splitForAllCo_maybe`, which doesn't look for `Refl`s. Perhaps it should. - The ''only'' way `InstCo`s can come into being is in the coercion optimizer. There is no call to `mkInstCo` beyond it. So perhaps we can take that into account when designing these functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 15:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 15:31:11 -0000 Subject: [GHC] #14965: GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails In-Reply-To: <044.b955c5c690cd54fa2244c5effa4f7808@haskell.org> References: <044.b955c5c690cd54fa2244c5effa4f7808@haskell.org> Message-ID: <059.81eb3f306ccb67e40e731e5d3ef55f6d@haskell.org> #14965: GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: DWARF Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14965 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4534 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: D4534 => Phab:D4534 * resolution: => fixed * milestone: => 8.4.2 Comment: This is fixed in 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 15:33:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 15:33:52 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.3f6ffd10219a2a654407770219b2f8cf@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time performance bug * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 18:32:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 18:32:25 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.7de9634080183ce482c639f3961e850a@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This is not a bug but I am trying to understand the ~~implication~~ > significance of `-XQuantifiedConstraints`. > > [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- > outsidein.pdf OutsideIn(X)] (section **2.4**) tells us `test` actually > has a principle type when we have implication constraints) > > {{{#!hs > data T :: Type -> Type where > T1 :: Int -> T Bool > T2 :: T a > > test :: (a~Bool => b~Bool) => T a -> b -> b > test (T1 n) _ = n > 0 > test T2 r = r > }}} > > that subsumes > > {{{#!hs > test1 :: T a -> a -> a > test1 = test > > test2 :: T a -> Bool -> Bool > test2 = test > }}} > > Now that we have `-XQuantifiedConstraints` does this change the story at > all, if not you can close this.. New description: This is not a bug but I am trying to understand the ~~implication~~ significance of `-XQuantifiedConstraints`. [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- outsidein.pdf OutsideIn(X)] (section **2.4**) tells us `test` actually has a principal type when we have implication constraints) {{{#!hs data T :: Type -> Type where T1 :: Int -> T Bool T2 :: T a test :: (a~Bool => b~Bool) => T a -> b -> b test (T1 n) _ = n > 0 test T2 r = r }}} that subsumes {{{#!hs test1 :: T a -> a -> a test1 = test test2 :: T a -> Bool -> Bool test2 = test }}} Now that we have `-XQuantifiedConstraints` does this change the story at all, if not you can close this.. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 19:23:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 19:23:30 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.ea7a42a851f6462bb2b2556b6ee57c47@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): I've developed a possible fix for this ticket, but I have some questions about the nature of GHC's runtime symbols. Depending on the answers, I'm afraid my fix will just push the problem to a different location, and not really be a fix at all. This ticket's description states that it's error-prone for a developer to keep GHC's runtime symbols in sync between the runtime system's C header files (*.h) and C source files (*.c). The goal is to remove the developer from having to decide if the runtime symbols are in sync, and have an algorithm perform that task instead. The runtime symbols naturally fall into mathematical sets: * Set "A": All runtime function symbols in `includes/Rts.h` (and its included headers). * Set "B": All runtime function symbols exported by the `rtsSyms[]` array in `rts/RtsSymbols.c`. It should be a simple matter of calculating the set difference `(A - B)` to discover what symbols aren't being exported. Unfortunately, it's not so simple. Set "A" has about 870 symbols, and set "B" about 560. This means roughly 310 symbols aren't being exported. These symbols appear to be legitimately intended to never be exported. We'll call this set "C": * Set "C": All runtime function symbols in `includes/Rts.h` intentionally **NOT** exported by the `rtsSyms[]` array in `rts/RtsSymbols.c`. Now the algorithm becomes `(A - B) - C`, which works. But there's a problem. The contents of sets "A" and "B" can be determined algorithmically. However, the contents of set "C" must be determined semantically - i.e. a developer must decide what symbols should and should not be in set "C". The goal of removing the developer from the decision-making process has not been met. Questions: * Should set "C" exist? As long as it does, a completely algorithmic solution will never be possible, because a developer will still be required to make a decision about the contents of set "C". In other words, the current problem of a developer forgetting to add a symbol to set "B" (the rtsSyms[] array in rts/RtsSymbols.c), is replaced by a new problem of a developer deciding what symbols belong in set "C". My fix would just shift the problem to new location (along with the addition of about 1000 lines of new code and documentation in GHC's code base). * The only fix I can think of is to eliminate set "C" by requiring any symbol appearing in set "A" to also appear in set "B". Is this feasible? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 22:02:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 22:02:51 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.926b973c9dfc360e68c358e96c04163d@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Interestingly, the coercion optimizer will not work on InstCo ... (Refl ...). At first I disagreed. The first equation for `opt_co4` is this {{{ opt_co4 env sym rep r (InstCo co1 arg) -- forall over type... | Just (tv, kind_co, co_body) <- splitForAllCo_maybe co1 = opt_co4_wrap (extendLiftingContext env tv (arg' `mkCoherenceRightCo` mkSymCo kind_co)) sym rep r co_body }}} If `arg` is `Refl` then `kind_co` is also `Refl`, so `mkCoherenceRightCo` is a no-op. So the argument to `extendLiftingContext` is `Refl`; and it looks like this {{{ extendLiftingContext (LC subst env) tv (Refl _ ty) = LC (extendTvSubst subst tv ty) env }}} That is, it just extends the `TvSubst`. And that looks exactly what happens in `mkInstCo`. So I think that `opc_co4` does in fact do exactly the same. But perhaps spotting a `Refl` argument would be a bit more direct? Meanwhile * I agree that `kind_co` should be substituted. But how? By calling `ope_co4` on it? Or `opt_co3`? I don't understand the hierarchy of `opt_co` functions. * I find that code for `extendLiftingContext` hard to grok. In the `Refl` case we extend the `TvSubst`; otherwise we extend the `LiftCoEnv`. Very mysterious. I looked at it a bit, but got lost in the deeply cryptic `liftEnvSubst`. Returning to the main event, however, I agree we won't get an efficient substitution, because in the example in comment:13 the `splitForAllCo_maybe` will fail -- because `co1` is another `InstCo`! What we need, as usual, is to accumulate those arguments in a list; then in the middle we should find a stack of `ForAllCo`s; and we can extend the substitution as we pair them up. Would that be right? Perhaps that's why Tobias saw no improvement -- though I'm a bit surprised that it got a lot worse. > opt_co4 uses splitForAllCo_maybe, which doesn't look for Refls. Perhaps it should. You mean that `Refl (forall a. ty)` can be regarded as a form of `ForAllCo`? Especially since `mkForAllCo` goes to some trouble to build a `Refl` if it can. So surely yes, `splitForAllCo_maybe` should split a `Refl (forall a.ty)`. > The only way InstCos can come into being is in the coercion optimizer. There is no call to mkInstCo beyond it. So perhaps we can take that into account when designing these functions. Not true: `pushCoTyArg` calls `mkInstCo`; that's where this entire conversation started! And I don't know what it means to "take it into account" Things to do * Fix the missing substitution in `opt_co4` * Fix `splitForAllCo_maybe` * Fix `opt_co4` to behave well on deeply nsted `InstCos` Might you do these -- you are more likely to get them right than me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 22:03:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 22:03:31 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.62cc77c9347399aaf77de9a66f50774f@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi, Thanks for looking into this again. So to give some context, not all symbols in set `B` are actually important. `rtsSyms` exists to cover up a deficiency of the fact that the runtime linker itself is also a haskell process: We cannot have two versions of the rts loaded in one process. This means we cannot link against `libRTS` to provide the symbols that are required for a Haskell program to run when loading in haskell libraries. This works by providing a set of symbols that will be loaded from the running Haskell program. Effectively providing the code just loaded access the the running RTS. Now why don't we just export all symbols from the running process? Because we don't want to force the user to have to use the same implementation of standard functions that we have chosen, and more importantly, we don't want to conflict if the user does specify another implementation. We actually do have this specific case, those are the symbols exported by the `SymI_HasProto_deprecated` macro but these are a manually curated set. So essentially set `B` should be all `SymI` values excluding `SymI_HasProto_deprecated` ones. However in this particular case it doesn't matter much. But just so you know what the symbols do. Now why only `SymI`? because in certain cases, like when the code is dynamically linked, the symbols can just be gotten from the dynamically loaded shared libraries. In that case the runtime linker is not the one providing the symbols, but we do know that they are there. > Should set "C" exist? As long as it does, a completely algorithmic solution will never be possible, because a developer will still be required to make a decision about the contents of set "C". In other words, the current problem of a developer forgetting to add a symbol to set "B" (the rtsSyms[] array in rts/RtsSymbols.c), is replaced by a new problem of a developer deciding what symbols belong in set "C". My fix would just shift the problem to new location (along with the addition of about 1000 lines of new code and documentation in GHC's code base). Can you give a few examples of which symbols are in set C? one way to reduce this set C may be to check the symbols defined in the rts. and restrict C to only those symbols that are actually defined in one of the RTS libraries. The RTS libraries are ABI compatible (mostly, I think only profiling isn't but I don't remember of the top of my head.). > The only fix I can think of is to eliminate set "C" by requiring any symbol appearing in set "A" to also appear in set "B". Is this feasible? Probably not, aside from the runtime cost it carries it also increases the risk of symbol collisions with user libraries. But again this really depends on what's in C. I guess the way forward really depends on what's in C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 22:52:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 22:52:53 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.f328ec92e90653e99e6d530d2e9c15e6@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D4244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 23:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 23:48:06 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.ae8e9010d3bd80a4a1d203a44e4febb9@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm looking at this exception-semantics stuff again, as I try to make sense of the nested CPR stuff #1600 and Phab:D4244. I'm puzzled. * The strrictness 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 loosk t me as if `catchRetry#` was left out by mistake. Right, David? And if so, that's the last use of `catchArgDmd` and I think that all the tricky `ThrowsExn` machinery can disappear. Incidentally, 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 `Note [Strictness for mask/unmask/catch]` in `primops.txt/pp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 23:52:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 23:52:42 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.9d3fab9456d965db4b5f6fe1ceb2c9e6@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chris_r_timmons): * Attachment "Set_A_-_Symbols_from_includes-rts_dot_h" added. Runtime symbols set "A", as decribed in comment #10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 23:53:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 23:53:22 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.652472ecf47c626f04bd469a61e75e53@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chris_r_timmons): * Attachment "Set_B_-_Symbols_from_rts-RtsSymbols_dot_c" added. Runtime symbols set "B", as decribed in comment 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 23:53:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 23:53:40 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.76b57d99a670c5ce5fbc90c75ee76bd3@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chris_r_timmons): * Attachment "Set_C_-_Symbols_from_includes-rts_dot_h NOT exported from rts-RtsSymbols_dot_c" added. Runtime symbols set "C", as decribed in comment 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 3 23:54:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Apr 2018 23:54:37 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.8051653976804b47ed033f0fad592e18@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): I've attached three files containing runtime symbol sets as described in the comment above. The symbols were generated on Windows/MSYS2, using GHC code that's about two weeks old. Given what I'm learning about the runtime system, I'm not optimistic that the detection of missing runtime symbols can be fully automated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 00:35:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 00:35:22 -0000 Subject: [GHC] #14988: Memory strain while compiling HLint In-Reply-To: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> References: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> Message-ID: <061.4a641aa4217d5f5a340edc2f8dd9224a@haskell.org> #14988: Memory strain while compiling HLint -------------------------------------+------------------------------------- Reporter: mcandre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mcandre): Update: The specific error I'm getting is {{{ $ cabal install HLint ... ghc: mmap 131072 bytes at 0x0: Operation not permitted }}} This happens in HardenedBSD, does not happen in FreeBSD. This happens when ghc tries to build HLint's haskell-src-exts, uniplate, and/or aeson dependency libraries. This does not happen in HardenedBSD for smaller package trees like shake or QuickCheck. I tried adding swap space to provide a larger memory pool, but top showed cabal/ghc never dipping into swap space, so I suppose this mmap error means something else besides out-of-memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 00:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 00:35:50 -0000 Subject: [GHC] #14988: Memory strain while compiling HLint In-Reply-To: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> References: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> Message-ID: <061.5112375ea35567bc26259c2ad2ac8e92@haskell.org> #14988: Memory strain while compiling HLint -------------------------------------+------------------------------------- Reporter: mcandre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mcandre): I'm using ghc v8.0.2, cabal-install v1.24.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 03:10:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 03:10:05 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.526144741ea0008a29a223ef021874b5@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I ''thought'' you didn't like the performance implications and we reverted the change to `TopDmd`, but maybe I'm wrong. I can check if you like. I left the `retry` stuff alone on the basis that I didn't feel I understood it well enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 07:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 07:37:32 -0000 Subject: [GHC] #14998: Sort out the strictness mess for exceptions Message-ID: <046.d3096c43bf101ad7c81045eb41e2848f@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 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: -------------------------------------+------------------------------------- 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 * `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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 07:43:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 07:43:13 -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.66e53b9a589b5a96dff602ac2335065c@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 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: => Exceptions 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 > * `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. 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 Wed Apr 4 07:45:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 07:45:10 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.831a353ef7e5eb9855027f117ac0f5d7@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK thanks. I've opened #14998. > we reverted the change to TopDmd I don't think so: the first arg of `catch#` is still `lazyApply1Dmd`. And maybe it should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 08:28:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 08:28:56 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.cc2b2a03c43d954fda68b56091941339@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I regret to report that even after Richard's "solveEqualties" patch #14066, the example in comment:2 yields {{{ T14040.hs:91:28: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180402 for x86_64-unknown-linux): No skolem info: [a1_aWV[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} This arises during the error-report-generation stage. The residual constraint is this {{{ reportUnsolved (after zonking): Free tyvars: (t_a1e3[tau:2] :: Proxy x_a1dP[sk:2]) a_aWV[sk:1] Tidy env: ([ESf6y :-> 1, ESf7a :-> 1, ESfO0 :-> 2, ESgiS :-> 1], [aWV :-> a1_aWV[sk:1], a1dP :-> x_a1dP[sk:2], a1dQ :-> a_a1dQ[sk:2], a1e3 :-> t0_a1e3[tau:2]]) Wanted: WC {wc_impl = Implic { TcLevel = 2 Skolems = (x_a1dP[sk:2] :: a_aWV[sk:1]) a_a1dQ[sk:2] (f_a1dR[sk:2] :: forall (x :: a_a1dQ[sk:2]). Proxy x ~> *) (x_a1dS[sk:2] :: a_a1dQ[sk:2]) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [D] _ {0}:: Sing t_a1e3[tau:2] -> Sing (Apply (f_a1dR[sk:2] x_a1dP[sk:2]) t_a1e3[tau:2]) (CHoleCan: TypeHole(_))} Binds = EvBindsVar Needed inner = [a2hM :-> co_a2hM, a2hN :-> co_a2hN, a2hO :-> co_a2hO, a2hQ :-> co_a2hQ, a2hR :-> co_a2hR, a2hS :-> co_a2hS, a2i2 :-> $dIP_a2i2] Needed outer = [a2hM :-> co_a2hM, a2hN :-> co_a2hN, a2hO :-> co_a2hO, a2hQ :-> co_a2hQ, a2hR :-> co_a2hR, a2hS :-> co_a2hS] the type signature for: dapp :: forall (x :: a_aWV[sk:1]) a (f :: forall (x :: a). Proxy x ~> *) (x :: a). Sing (f x) -> Sing x -> f x @@ 'Proxy } }}} And indeed you can see that the skolem `a1_aWV` is not bound by any implication. This must be a bug. Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:03:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:03:14 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong Message-ID: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Minimized `stg_catch_frame` (`Small.cmm`): {{{ #define CATCH_FRAME 34 #define SIZEOF_StgCatchFrame (SIZEOF_StgHeader+16) INFO_TABLE_RET(stg_catch_frame, CATCH_FRAME, bits64 info_ptr, bits64 exceptions_blocked, gcptr handler) return (gcptr ret) { unwind Sp = Sp + SIZEOF_StgCatchFrame; return (ret); } }}} Compile `"inplace/bin/ghc-stage2" -O2 -g -c Small.cmm` using GHC HEAD. `objdump -D` for `stg_catch_frame_info`: {{{ 0000000000000010 : 10: 48 83 c5 18 add $0x18,%rbp 14: ff 65 00 jmpq *0x0(%rbp) }}} `readelf --debug-dump=frames-interp Small.o`: {{{ Contents of the .debug_frame section: 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra 0000000000000000 rbp+0 v+0 s c+0 00000018 000000000000002c 00000000 FDE cie=00000000 pc=000000000000000f..0000000000000017 LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 s c+0 000000000000000f rbp+24 v+0 s c+0 0000000000000010 rbp+0 v+0 s c+0 }}} **How do I know this is wrong?** http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf has a nice example in Appendix 5 (page 101 of the pdf). The question that I had was if the CFA value at LOC is after or before the instruction at LOC executes. Appendix 5 clearly shows that it's **before**. Hence for LOC = 0x10 here CFA shouldn't have changed. It can and should change at LOC = 0x14. For comparison this is what `8.0.2` produced (and it worked more often): {{{ 0000000000000010 : 10: 48 83 c5 18 add $0x18,%rbp 14: ff 65 00 jmpq *0x0(%rbp) }}} {{{ Contents of the .debug_frame section: 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra 0000000000000000 rbp+0 v+0 s c+0 00000018 0000000000000024 00000000 FDE cie=00000000 pc=000000000000000f..0000000000000017 LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 s c+0 000000000000000f rbp+24 v+0 s c+0 }}} Debugging follows in the comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:06:32 -0000 Subject: [GHC] #15000: Add a linter for debug information (-g) Message-ID: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> #15000: Add a linter for debug information (-g) -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- There are some sanity checks we can do. For example if you see following Cmm: {{{ unwind Sp = Sp + 16 Sp = Sp + 16 unwind Sp = Sp + 64 }}} You can tell that it's wrong because it's clear how `Sp` changed between the two unwind points. I think this would fit well with the Cmm linter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:08:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:08:23 -0000 Subject: [GHC] #15000: Add a linter for debug information (-g) In-Reply-To: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> References: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> Message-ID: <061.0be7fe0d954fc7f6bd9e0d47ca6ba53a@haskell.org> #15000: Add a linter for debug information (-g) -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 niteria): * cc: simonmar, bgamari (added) * owner: (none) => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:09:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:09:02 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.019e8d21aaad9079105b618208a59ded@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 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 niteria): * owner: (none) => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:16:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:16:17 -0000 Subject: [GHC] #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias In-Reply-To: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> References: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> Message-ID: <066.2cd2d0166a44f69573216953d81936c2@haskell.org> #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Iceland Jack! You are torturing me. Here is what is happening. To deal with `yo` we want to solve {{{ [W] Implies (Yo a b) (Implies a b) }}} We proceed as follows {{{ [W] Implies (Yo a b) (Implies a b) ===> (apply instance) [W] (forall {}. Yo a b => Implies a b) -- A quantified constraint ===> build implication constraint forall {}. [G] Yo a b => [W] Implies a b }}} So we have a Given constraint `[G] Yo a b`. So we expand its superclasss giving {{{ [G] (forall xx. Implies (Implies b xx) (Implies a xx)) }}} and try solving {{{ forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) => [W] Implies a b }}} Ok... now we return attention to that Wanted and try to solve it. Use the top level instance! Gives us {{{ forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) => [W] Implies a b ===> (top level instance) forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) => [W] (a => b) ===> (build implication constraint) forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) => forall {}. [G] a => [W] b }}} Now we seem to be stuck so we expand another layer of superclasses. We can take the superclasses of that quantified constraint (as in [https://github.com/Gertjan423/ghc-proposals/blob/quantified- constraints/proposals/0000-quantified-constraints.rst Section 3.4 of the proposal]) giving us {{{ forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) [G] (forall xx. Implies b xx => Implies a xx) --- Next superclass => forall {}. [G] a => [W] b }}} We are still stuck, so expand sueprclasses again: {{{ forall {}. [G] Yo a b [G] (forall xx. Implies (Implies b xx) (Implies a xx)) [G] (forall xx. Implies b xx => Implies a xx) [G] (forall xx. Implies b xx => a => xx) --- Next superclass => forall {}. [G] a => [W] b }}} And now we are in a very bad place. We have a Given quantified constraint that lets us solve ANY constraint `xx` (for any `xx`!). But in solving it, we just get another bigger problem to solve. So solving diverges. I hvae no idea what you are trying to do, but GHC seems to be behaving quite reasonably. Why does it "work" you have `=>` instead of `Implies` in the superclass for `Yo`? (The instance for `Yo` is irrelevant; just delete it.) By a fluke. We get as before {{{ forall {}. [G] Yo a b => [W] Implies a b }}} But we expand the given superclasses layer by layer, so before trying to solve the Wanted we get {{{ forall {}. [G] Yo a b [G] (forall xx. Implies b xx => Implies a xx) -- Superclass! => [W] Implies a b }}} Now it just happens that the wanted matches the quantified constraint, we can apply that local instance decl giving `[W] Implies b b` which we can solve. ---------------- There are several difficulties here. * First, your setup is weird. If you expand superclasses enough, you get to prove any constraint whatsoever, and that is plainly stupid. * I don't like flukes. Maybe we should not make use the local instance (quantified constraint) if the constraint we are solving also matches a global instance. Curerntly we make the local ones "shadow" the global ones. * The superclass expansion is a bit less aggressive than I expected; I'm not sure why. If we expanded more vigorously, the fluke would happen both times. I'm not sure how hard to work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:20:16 -0000 Subject: [GHC] #15000: Add a linter for debug information (-g) In-Reply-To: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> References: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> Message-ID: <061.c36f25423827acc9da4d9dfe1d3602ac@haskell.org> #15000: Add a linter for debug information (-g) -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: | -------------------------------------+------------------------------------- Description changed by niteria: Old description: > There are some sanity checks we can do. > > For example if you see following Cmm: > > {{{ > unwind Sp = Sp + 16 > Sp = Sp + 16 > unwind Sp = Sp + 64 > }}} > > You can tell that it's wrong because it's clear how `Sp` changed between > the two unwind points. > > I think this would fit well with the Cmm linter. New description: There are some sanity checks we can do. For example if you see the following Cmm: {{{ unwind Sp = Just Sp + 16; Sp = Sp + 16; unwind Sp = Just Sp + 64; }}} You can tell that it's wrong because it's clear how `Sp` changed between the two unwind points. I think this would fit well with the Cmm linter. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 09:50:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 09:50:32 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.a03b42758f36289a9da3932536ef62b9@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 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 niteria): First thing is to understand how to read unwind information in Cmm. If you have: {{{ A // starts at addr X and ends at addr Y unwind Sp = Just Sp + 16; B // starts at addr Y and ends at addr Z }}} Does the unwind information reflect the state after `A` or `B`? If it reflects the state after `A` then you'd expect the LOC to be `Y`. If it reflects the state after `B` then you'd expect the LOC to be `Z`. I couldn't find a relevant note, so I resorted to experimentation. It appears that the unwind annotation reflects the state after `A`, but before `B`. With that in mind we can look at relevant Cmm dumps (`-ddump-cmm -ddump- opt-cmm -ddump-cmm-proc -ddump-cmm-verbose`): {{{ ==================== Parsed Cmm ==================== [stg_catch_frame_ret() // [R1] { info_tbl: [(c5, label: stg_catch_frame_info rep:tag:34 StackRep [True, False])] stack_info: arg_space: 32 updfr_space: Just 8 } {offset c5: // c1 _c1::I64 = I64[(old + 32)]; // CmmAssign _c2::I64 = I64[(old + 24)]; // CmmAssign _c3::P64 = P64[(old + 16)]; // CmmAssign _c4::P64 = R1; // CmmAssign //tick src unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall } }] ==================== Post control-flow optimisations ==================== {offset c5: // c1 _c1::I64 = I64[(old + 32)]; // CmmAssign _c2::I64 = I64[(old + 24)]; // CmmAssign _c3::P64 = P64[(old + 16)]; // CmmAssign _c4::P64 = R1; // CmmAssign //tick src unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== Post common block elimination ==================== {offset c5: // c1 _c1::I64 = I64[(old + 32)]; // CmmAssign _c2::I64 = I64[(old + 24)]; // CmmAssign _c3::P64 = P64[(old + 16)]; // CmmAssign _c4::P64 = R1; // CmmAssign //tick src unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== Post switch plan ==================== {offset c5: // c1 _c1::I64 = I64[(old + 32)]; // CmmAssign _c2::I64 = I64[(old + 24)]; // CmmAssign _c3::P64 = P64[(old + 16)]; // CmmAssign _c4::P64 = R1; // CmmAssign //tick src unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== Layout Stack ==================== {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind _c1::I64 = I64[Sp]; // CmmAssign _c2::I64 = I64[Sp + 8]; // CmmAssign _c3::P64 = P64[Sp + 16]; // CmmAssign _c4::P64 = R1; // CmmAssign //tick src unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign unwind Sp = Just Sp + 0; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== Sink assignments ==================== {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind R1 = R1; // CmmAssign unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== Post common block elimination 2 ==================== {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind R1 = R1; // CmmAssign unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } ==================== CAFEnv ==================== [(c5, {})] ==================== after setInfoTableStackMap ==================== stg_catch_frame_ret() // [R1] { info_tbl: [(c5, label: stg_catch_frame_info rep:tag:34 StackRep [True, False])] stack_info: arg_space: 32 updfr_space: Just 8 } {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind R1 = R1; // CmmAssign unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } } ==================== Post control-flow optimisations ==================== stg_catch_frame_ret() // [R1] { info_tbl: [(c5, label: stg_catch_frame_info rep:tag:34 StackRep [True, False])] stack_info: arg_space: 32 updfr_space: Just 8 } {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind R1 = R1; // CmmAssign unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } } ==================== Post CPS Cmm ==================== [stg_catch_frame_ret() // [R1] { info_tbl: [(c5, label: stg_catch_frame_info rep:tag:34 StackRep [True, False])] stack_info: arg_space: 32 updfr_space: Just 8 } {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind R1 = R1; // CmmAssign unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } }] ==================== Optimised Cmm ==================== stg_catch_frame_ret() // [R1] { [(c5, stg_catch_frame_info: const 66; const 34;)] } {offset c5: // c1 unwind Sp = Just Sp + 24; // CmmUnwind //tick src unwind Sp = Just Sp + 24; // CmmUnwind // nop unwind Sp = Just Sp; // CmmUnwind Sp = Sp + 24; // CmmAssign call (P64[Sp])(R1) args: 8, res: 0, upd: 8; // CmmCall } } }}} The first place where things go obviously wrong is `Layout Stack`. Let's focus on this fragment: {{{ unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign unwind Sp = Just Sp + 0; // CmmUnwind Sp = Sp + 24; // CmmAssign }}} It looks like we swapped the unwind with the `Sp` update. Here's what we'd want: {{{ unwind Sp = Just Sp + (8 + 16); // CmmUnwind R1 = _c4::P64; // CmmAssign Sp = Sp + 24; // CmmAssign unwind Sp = Just Sp + 0; // CmmUnwind }}} It turns out that the place that's responsible for this is `manifestSp` in `CmmLayoutStack`. After a small change: {{{ diff --git a/compiler/cmm/CmmLayoutStack.hs b/compiler/cmm/CmmLayoutStack.hs index d2525d1..1e8c7c4 100644 --- a/compiler/cmm/CmmLayoutStack.hs +++ b/compiler/cmm/CmmLayoutStack.hs @@ -860,7 +860,7 @@ manifestSp dflags stackmaps stack0 sp0 sp_high = block where sp_unwind = CmmRegOff spReg (sp0 - wORD_SIZE dflags) - -- Add unwind pseudo-instruction right before the Sp adjustment + -- Add unwind pseudo-instruction right after the Sp adjustment -- if there is one. add_adj_unwind block | debugLevel dflags > 0 @@ -870,8 +870,9 @@ manifestSp dflags stackmaps stack0 sp0 sp_high = block where sp_unwind = CmmRegOff spReg (sp0 - wORD_SIZE dflags - sp_off) - final_middle = maybeAddSpAdj dflags sp_off - . add_adj_unwind + final_middle = + add_adj_unwind + . maybeAddSpAdj dflags sp_off . add_initial_unwind . blockFromList . map adj_pre_sp }}} We get: {{{ 0000000000000010 : 10: 48 83 c5 18 add $0x18,%rbp 14: ff 65 00 jmpq *0x0(%rbp) }}} {{{ Contents of the .debug_frame section: 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra 0000000000000000 rbp+0 v+0 s c+0 00000018 000000000000002c 00000000 FDE cie=00000000 pc=000000000000000f..0000000000000017 LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 s c+0 000000000000000f rbp+24 v+0 s c+0 0000000000000014 rbp+0 v+0 s c+0 }}} As a side note, the manually inserted unwind info in `stg_catch_frame` appears to be redundant. Layout Stack appears to be doing the same thing. 5279b08ba3f01e4b7e28d12b2751413d789d9fbe is what introduced this behavior, so I'd like Ben to check if I didn't go off the rails somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 10:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 10:23:57 -0000 Subject: [GHC] #15000: Add a linter for debug information (-g) In-Reply-To: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> References: <046.8e0b3e2dd9f9e9fa32d894ece6e34e88@haskell.org> Message-ID: <061.c821c7d2403b2126ea645387f7c220e8@haskell.org> #15000: Add a linter for debug information (-g) -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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): phab:D4559 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D4559 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 12:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 12:23:55 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.c4c7601ff25aff19bfbefc18262dfdc0@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypedHoles Operating System: 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): Another issue is that using a standalone hole gives an error in HEAD (not in 8.4): {{{ Prelude> _ :1:1: error: GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 12:36:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 12:36:10 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.f5477063814dc0a7f00184840504648a@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): I'd like to ask Simon a 'History of Haskell' type question while this development work is fresh in memory: The attention it gets in OutsideIn(X) shows the idea has stayed in the back of your mind since 2000. ghc's type inference engine gets radical surgery every half-decade or so. Did something happen that got `-XQuantifiedConstraints to a 'sweet spot'?/changed **4.2**'s evaluation as it being "not practical"? Or could it as easily have been developed in 2005 or 2010 or ...? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 13:05:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 13:05:20 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.c748d83bf7dc5a2730c702ba275777cf@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 simonpj]: > If `arg` is `Refl` then `kind_co` is also `Refl`, Why do you say this? `kind_co` must be reflexive, but it needn't be `Refl`. Especially because it hasn't been optimized yet! > But perhaps spotting a `Refl` argument would be a bit more direct? I think it would. > > Meanwhile > * I agree that `kind_co` should be substituted. But how? By calling `ope_co4` on it? Or `opt_co3`? I don't understand the hierarchy of `opt_co` functions. You call the highest-numbered one for which you can meet the preconditions. In this case, that's `opt_co4` because we know `kind_co`'s role (nominal), and it should keep that role after optimization. > * I find that code for `extendLiftingContext` hard to grok. In the `Refl` case we extend the `TvSubst`; otherwise we extend the `LiftCoEnv`. Very mysterious. I looked at it a bit, but got lost in the deeply cryptic `liftEnvSubst`. You're right. This needs more documentation -- but a quick glance at this all suggests the code is currently correct. > > What we need, as usual, is to accumulate those arguments in a list; Yes, of course. > You mean that `Refl (forall a. ty)` can be regarded as a form of `ForAllCo`? Especially since `mkForAllCo` goes to some trouble to build a `Refl` if it can. So surely yes, `splitForAllCo_maybe` should split a `Refl (forall a.ty)`. Yes, that's exactly what I meant. > > > The only way InstCos can come into being is in the coercion optimizer. I was searching over a very old checkout of the codebase, and I wrongly assumed this hadn't changed. You're right of course. > Things to do > * Fix the missing substitution in `opt_co4` > * Fix `splitForAllCo_maybe` > * Fix `opt_co4` to behave well on deeply nsted `InstCos` > Might you do these -- you are more likely to get them right than me. OK. Hopefully can do in the next two weeks -- but I can't promise sooner. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 13:12:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 13:12:47 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.4c6a537094eecd2af07ed01b2c9b8fa4@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): The big thing that changed in the implementation was when we first had a separate "constraint solver" including implication constraints. I can't quite remember when we first instituted that, but some Git history mining might tell us. That made quantified constraints vastly easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 13:23:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 13:23:19 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.b5536bf52407b70da61d97f7a868cfc0@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire Comment: Fine, thanks. Let's park this for a couple of weeks then. It's not urgent -- but there is money on the table here that is not hard to get at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 13:25:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 13:25:26 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.d6fb6862ad6ebfb9881292bc99214c2c@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 13:25:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 13:25:42 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.aefdabad9f995abcecab80f7f8b0f33a@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 14:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 14:23:46 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.c766bd198590d4230341f8ce94e3a5fb@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm 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 sgraf): * cc: simonmar, michalt, bgamari (added) Comment: (Calling in a few people from https://phabricator.haskell.org/D4417 for advise) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 14:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 14:25:43 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.c61f2725a4e643e30477fc3934d5e664@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * differential: => Phab:D4417 * related: => 12915 14226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 14:28:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 14:28:02 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.395e6cd107f9c8ea1b66ae28b1a45e7e@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 15:10:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 15:10:46 -0000 Subject: [GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule In-Reply-To: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> References: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> Message-ID: <065.a20d188e3d80abfe40ac69188c641365@haskell.org> #14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType 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): Hm. After thinking about this some more, I'm not 100% convinced that this is an inconsistent design. The issue is that the `forall`-or-nothing rule applies to //top-level// type signatures. But data type return kinds are not truly top-level, as they can mention type variables bound before it. For instance, in this example: {{{#!hs data Foo2 (x :: b) :: forall a. a -> b -> Type }}} Here, the explicit return kind is only a small part of `Foo2`'s kind. The full shebang would be (using an [https://github.com/ghc-proposals/ghc- proposals/pull/54 explicit kind signature]): {{{#!hs type Foo2 :: forall b. b -> forall a. a -> b -> Type }}} In that sense, data type return kinds don't need to satisfy the `forall `-or-nothing rule, since they're not actually the thing at the top level. A similar phenomenon occurs at the term level. GHC accepts this: {{{#!hs {-# LANGUAGE RankNTypes #-} f :: (forall a. a -> b -> Int) f _ _ = 42 }}} That's because in some sense, `(forall a. a -> b -> Int)` isn't the real top-level type signature here. The //real// top-level type signature is revealed if you query GHCi: {{{ λ> :type +v f f :: forall b a. a -> b -> Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 15:14:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 15:14:30 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.d6e897145dbfb7ed3684d243b75d208b@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528, Wiki Page: | Phab:D4562 -------------------------------------+------------------------------------- Changes (by voanhduy1512): * differential: Phab:D4528 => Phab:D4528, Phab:D4562 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 15:26:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 15:26:05 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.036788fd326ae3c33ea2e75f7b922acb@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528, Wiki Page: | Phab:D4562 -------------------------------------+------------------------------------- Comment (by voanhduy1512): Replying to [comment:12 MikolajKonarski]: > I'm not sure, because many of the new warnings are added with the intention of adding them to -Wall sooner or later, so the positive list would need to grow, too. Also, the list of warnings included in -Wall is much longer than the list of warnings excluded. An option is to provide both lists and remark that if a warning is on neither list, it must be a new one and please file a Trac ticket. Then we are at least not stating a falsehood. I try to build a list status of options here https://gist.github.com/voanhduy1512/7769e04b925069170212400b57f5d4a3. Right now there is more options which excluded in `-Wall` than included. Maybe it will be change in future but i think it's easier to add positive list. For example i add a option to `-Wall` but forgot to update the doc, it's easy to update the doc to correct state just by looking at the code. As for current state, i need to get all options, minus all default options, minus all `-W`, `-Wall`, to get the real list that are not in `-Wall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 15:28:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 15:28:16 -0000 Subject: [GHC] #13845: Runtime linker too eagerly checks for symbol names In-Reply-To: <050.86cc0f10c3948104df211f0c9ac47a26@haskell.org> References: <050.86cc0f10c3948104df211f0c9ac47a26@haskell.org> Message-ID: <065.631e2e091f5e104a712363936796f95d@haskell.org> #13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | 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 Comment: Indeed, you can also work around this by using `-fobject-code`, which does //not// load all top-level definitions. {{{ $ runghc --ghc-arg=-fobject-code Bug.hs Hello, World! }}} In short, this isn't a real bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:02:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:02:03 -0000 Subject: [GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule In-Reply-To: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> References: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> Message-ID: <065.d4d39617cc3a249430e952d79f1dc5be@haskell.org> #14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType 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): Very good points. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:02:22 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.35885b846f245f3454e04eb42d655ec5@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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 mcandre): Same goes for HardenedBSD; a handful of Haskell programs can run, but common things like HLint, aeson, and shake fail to compile or operate in W^X environments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:02:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:02:50 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders Message-ID: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Keywords: DmdAnal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D4244 | Wiki Page: -------------------------------------+------------------------------------- This is a follow-up on the first improvement in [Phab:D4244#126311]. Consider the following two functions with identical semantics: {{{ module Foo where {-# LANGUAGE BangPatterns #-} data Complex a = !a :+ !a foo :: Complex Double -> Int -> Complex Double foo !x 0 = x foo (a :+ b) _ = b :+ a bar :: Complex Double -> Int -> Complex Double bar x 0 = x bar (a :+ b) _ = b :+ a }}} In the corresponding simplified Core, `x` gets strictness `S(SS)` for `foo`, but only `S` for `bar`. We could do better by looking at `x`s type and see that its a product type with strict fields. This is because currently only case binders get [https://github.com/ghc/ghc/blob/72b5f649ede82ab3bb429aa72ee1c572f415b0eb/compiler/stranal/DmdAnal.hs#L253 special treatment] for strict product fields through `addDataConStrictness`. This ticket tracks if the same is worthwhile for lambda binders, as in `bar` above. Note that intuitively, this shouldn't make any difference because when we eventually unleash an `S` demand on a `Complex` constructor, we add `seqDmd` on strict fields anyway, amounting to `S(SS)`. So this is only a matter of recording things early because some parts of the analysis code might not be smart enough to add strict field demands by themselves. Also note that this doesn't touch impliciations on usage analysis at all, where unleashing the same `seqDmd` twice might mean we accidentally make some product field lose its single-entrieness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:04:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:04:32 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders In-Reply-To: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> References: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> Message-ID: <059.c24b8bb2fe7dafd089c13dca7561cf6d@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Resolution: | Keywords: DmdAnal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4244 D4563 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * differential: D4244 => D4244 D4563 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:05:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:05:40 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 In-Reply-To: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> References: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> Message-ID: <065.4b98f9850572dc5fc924c4c8cb6a864b@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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:D4564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:06:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:06:48 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders In-Reply-To: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> References: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> Message-ID: <059.d6121b1b679d5a33071842d5681a8e33@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Resolution: | Keywords: DmdAnal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4244 D4563 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * Attachment "nofib-table-all.txt" added. Results from NoFib run -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:07:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:07:46 -0000 Subject: [GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule In-Reply-To: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> References: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> Message-ID: <065.46d74c4510fd5e8d6270b88d6e0c4597@haskell.org> #14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: invalid | Keywords: TypeInType 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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: I think I'll close this as invalid, then. Feel free to reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:09:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:09:34 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders In-Reply-To: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> References: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> Message-ID: <059.5bebff067fe3670956aa6cd359b1975d@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Resolution: | Keywords: DmdAnal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4244 D4563 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): No changes to allocation, and +-0% on counted instructions. So, basically no change at all. Question is, do the prettier and more consistent results warrant the complexity? I'd say no, at least until there's a compelling reason we need this (as part of nested CPR). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:09:41 -0000 Subject: [GHC] #13363: Wildcard patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings (was: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings) In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.d4e7aea6c7c159e53dc410cf158b8635@haskell.org> #13363: Wildcard patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:10:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:10:44 -0000 Subject: [GHC] #12982: Missed constant folding oportunities In-Reply-To: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> References: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> Message-ID: <059.77a1aae487d08a7832edb8a4ca97d31a@haskell.org> #12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/hoopl | 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 Vyse007): I took a stab at this: thanks to Ben I was able to add a new {{{ PrimOp}}} for POW, along with some basic rules for folding in {{{ PrelRules.hs}}}. I eventually found myself stuck in {{{nativeGen/X86/CodeGen.hs}}} where we employ {{{getRegister}}} to find free registers for computation. I couldn't grok all of it so for I just copied the {{{triv_op}}} call for {{{MO_Mul}}} and it seemed to work fine; I understand that it's incorrect obviously, but I might need a little help in understanding what's the best solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:20:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:20:02 -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.90fe34a1f4ade27dba6ad2d230b76f88@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 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): * Attachment "nofib-table-all.txt" added. NoFib results of running the diff where we make `catch#` strict in its first argument (no validate run yet) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:23:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:23:13 -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.c323a89d41e68f29f8c207595488e988@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This measurement is for item 3 above for the following diff: {{{ diff --git a/compiler/prelude/primops.txt.pp b/compiler/prelude/primops.txt.pp index 43e8f535d3..c80b99268c 100644 --- a/compiler/prelude/primops.txt.pp +++ b/compiler/prelude/primops.txt.pp @@ -2051,7 +2051,7 @@ primop CatchOp "catch#" GenPrimOp -> State# RealWorld -> (# State# RealWorld, a #) with - strictness = { \ _arity -> mkClosedStrictSig [ lazyApply1Dmd + strictness = { \ _arity -> mkClosedStrictSig [ strictApply1Dmd , lazyApply2Dmd , topDmd] topRes } -- See Note [Strictness for mask/unmask/catch] }}} More or less no change, except for -0.1% in counted instructions for `grep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:28:04 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders In-Reply-To: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> References: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> Message-ID: <059.04228a08485141ce7b4af489e5019637@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Resolution: | Keywords: DmdAnal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4244 D4563 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree -- not worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:29:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:29:13 -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.3bcab1db04fb5950ef343e1f30732ce4@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 Operating System: 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! That includes recompiling all the libraries? (There are no explicit catch calls in nofib.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:35:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:35:01 -0000 Subject: [GHC] #12938: Polykinded associated type family rejected on false pretenses In-Reply-To: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> References: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> Message-ID: <062.e711699fb9370cc929f8f881bd89f0ac@haskell.org> #12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: As noted in comment:2 and comment:3, this has been fixed, and a regression test has been added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:41:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:41:11 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a type family to fail to typecheck In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.2257d1668bb6974895dab8ad7b1b6312@haskell.org> #14887: Explicitly quantifying a kind variable causes a type family to fail to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.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): The #12919 patch has landed. Interestingly, the program in comment:1 now gives a different error: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:43: error: • Expected kind ‘k’, but ‘a’ has kind ‘k0’ • In the first argument of ‘Proxy’, namely ‘(a :: k)’ In the kind ‘Proxy (a :: k)’ | 10 | type family Foo2 (k :: Type) (e :: Proxy (a :: k)) :: Type where {} | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:45:14 -0000 Subject: [GHC] #14764: Make $! representation-polymorphic In-Reply-To: <045.53df127e2c7b6a62fee488d1dc8b9a13@haskell.org> References: <045.53df127e2c7b6a62fee488d1dc8b9a13@haskell.org> Message-ID: <060.0b20842ea123bfb256ce40b13fd248e0@haskell.org> #14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4382 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed Comment: This was done in c9a88db3ac4f1c3e97e3492ebe076f2df6463540. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:50:07 -0000 Subject: [GHC] #12742: Instantiation of invisible type family arguments is too eager In-Reply-To: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> References: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> Message-ID: <062.c6ccd2b7db3189e9b08a6948e9d60e75@haskell.org> #12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T12742 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => dependent/should_compile/T12742 * status: new => closed * resolution: => fixed Comment: As noted in comment:2 and comment:3, this has been fixed, and a regression test has been added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:50:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:50:52 -0000 Subject: [GHC] #12938: Polykinded associated type family rejected on false pretenses In-Reply-To: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> References: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> Message-ID: <062.fe197552bec322da7e8fa9326b815778@haskell.org> #12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T12938 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => indexed-types/should_compile/T12938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 16:54:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 16:54:37 -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.2b665363bfa2cb41ddd9b842be8a327b@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I have stolen and refined a [https://github.com/sgraf812/ghc-benchmark docker setup] from Joachim that rebuilds every diff from scratch in a deterministic environment, so I think I measured the right thing. I can re-generate the logs to see if something messed up, if you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 17:00:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 17:00:35 -0000 Subject: [GHC] #15001: Add strict product field demands to lambda binders In-Reply-To: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> References: <044.dcb3c357027f89b6009a7e31adde800f@haskell.org> Message-ID: <059.e29db5b7e23c137e7ba032579e69885a@haskell.org> #15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Resolution: wontfix | Keywords: DmdAnal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): [Phab:D4244] Wiki Page: | [Phab:D4563] -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * differential: D4244 D4563 => [Phab:D4244] [Phab:D4563] * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 17:01:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 17:01:01 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.ae0a43b65f7b96425bc133003d53c86e@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528, Wiki Page: | Phab:D4562 -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Wow, great job. You are right, I had in mind the total number of warnings included by `-Wall`, but we list them separately for `on`, `-W` and `-Wall` and that's indeed the best way. I like your idea to provide a positive list for `-Wall`, as is the case for the other groups. Ben, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 18:53:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 18:53:25 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.1c02b0d01a1a3b615a4caa137afaa543@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints, wipT2893 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 Iceland_jack): * status: new => closed * resolution: => fixed Comment: Thanks for the feedback! I am/was interested in any thoughts (not just inference as I seem to have emphasized), closing :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 19:07:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 19:07:44 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.70eae8cccfddb7080b8f022dc3290182@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): hmm set C is somewhat suspicious.. some like `barf` `debugBelch` etc are internal symbols. what command did you use to generate the list? If they really are reachable from `Rts.h` it may be we have to move them to `internals` include file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 19:23:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 19:23:41 -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.759a422c25df644c4f4b831b311ad020@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well, let's declare victory on Item 4. Maybe it was the `mask#` primops (which still have `strictArgDmd` that were delivering the payoff. Next up: item 2. Could you remove the ! from the defns of `GHC.IO.catchException` and `catchAny`, and see if that has any perf impact? (And validate.) I think they are unnecessary. Next: item 1. Could you make `catchRetry#` have `lazyApply1Dmd` like `catch#` and see if that has any effect? If not, let's switch it. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 19:50:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 19:50:54 -0000 Subject: [GHC] #15002: Panic: collectNBinders Message-ID: <047.4bed8603d13edea0830249b5fa334075@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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: -------------------------------------+------------------------------------- Steps to reproduce: Download concurrent-extra-0.7.0.12 and add the following stack.yaml file: resolver: nightly-2018-04-04 system-ghc: true compiler-check: newer-minor {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.1.20180329 > stack build --library-profiling concurrent-extra-0.7.0.12: build (lib) Preprocessing library for concurrent-extra-0.7.0.12.. Building library for concurrent-extra-0.7.0.12.. [7 of 8] Compiling Control.Concurrent.Broadcast ( Control/Concurrent/Broadcast.hs, .stack- work/dist/x86_64-linux/Cabal-2.2.0.1/build/Control/Concurrent/Broadcast.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package concurrent-extra-0.7.0.12 using: /home/local/ANT/ericcro/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_2.2.0.1_ghc-8.4.1.20180329 --builddir=.stack- work/dist/x86_64-linux/Cabal-2.2.0.1 build lib:concurrent-extra --ghc- options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 19:51:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 19:51:27 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.d0e10b4fbd2ba61ac273dd51e684631a@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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 crockeea: Old description: > Steps to reproduce: > > Download concurrent-extra-0.7.0.12 and add the following stack.yaml file: > resolver: nightly-2018-04-04 > system-ghc: true > compiler-check: newer-minor > > {{{ > > ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.1.20180329 > > > stack build --library-profiling > concurrent-extra-0.7.0.12: build (lib) > Preprocessing library for concurrent-extra-0.7.0.12.. > Building library for concurrent-extra-0.7.0.12.. > [7 of 8] Compiling Control.Concurrent.Broadcast ( > Control/Concurrent/Broadcast.hs, .stack- > work/dist/x86_64-linux/Cabal-2.2.0.1/build/Control/Concurrent/Broadcast.p_o > ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > collectNBinders > 1 > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in > ghc:CoreSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > -- While building custom Setup.hs for package concurrent-extra-0.7.0.12 > using: > /home/local/ANT/ericcro/.stack/setup-exe-cache/x86_64-linux/Cabal- > simple_mPHDZzAJ_2.2.0.1_ghc-8.4.1.20180329 --builddir=.stack- > work/dist/x86_64-linux/Cabal-2.2.0.1 build lib:concurrent-extra --ghc- > options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > }}} New description: Steps to reproduce: Download concurrent-extra-0.7.0.12 and add the following stack.yaml file: {{{ resolver: nightly-2018-04-04 system-ghc: true compiler-check: newer-minor }}} Then run: {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.1.20180329 > stack build --library-profiling concurrent-extra-0.7.0.12: build (lib) Preprocessing library for concurrent-extra-0.7.0.12.. Building library for concurrent-extra-0.7.0.12.. [7 of 8] Compiling Control.Concurrent.Broadcast ( Control/Concurrent/Broadcast.hs, .stack- work/dist/x86_64-linux/Cabal-2.2.0.1/build/Control/Concurrent/Broadcast.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package concurrent-extra-0.7.0.12 using: /home/local/ANT/ericcro/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_2.2.0.1_ghc-8.4.1.20180329 --builddir=.stack- work/dist/x86_64-linux/Cabal-2.2.0.1 build lib:concurrent-extra --ghc- options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 19:59:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 19:59:14 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.a18b2fe1a678896fb96777bf4c18e270@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): Set `C` is just `A - B`. Referencing the attached `T12891.py` file, set `A` is generated with the `get_symbol_names` function. Set `B` is created by the `get_symbol_names_from_rts_symbols_c` function. (In the Python script I hard coded set `C`. I anticipated a developer would adjust its contents for correctness, at least until I could figure out a way to remove that requirement.) Regarding `barf` and `debugBelch` - they're declared in `includes/rts/Messages.h`, which is included by `includes/Rts.h`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 20:26:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 20:26:03 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.c33faf7eb088fc0fa28716a543f04e65@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => highest * version: 8.4.2-rc1 => 8.4.1 * component: Compiler => Profiling Comment: Thanks for the bug report. Note that one can also reproduce this with GHC 8.4.1 as well. Here is a minimal example: {{{#!hs module Bug where import Control.Concurrent.MVar (MVar, modifyMVar_, putMVar) import Data.Foldable (for_) broadcastThen :: Either [MVar a] a -> MVar (Either [MVar a] a) -> a -> IO () broadcastThen finalState mv x = modifyMVar_ mv $ \mx -> do case mx of Left ls -> do for_ ls (`putMVar` x) return finalState Right _ -> return finalState }}} {{{ $ ~/Software/ghc-8.4.1/bin/ghc -fprof-auto -prof -fforce-recomp -O1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in ghc:CoreSyn }}} Note that this bug goes away if one removes the `-O1` or `-fprof-auto` flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 20:31:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 20:31:40 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.9c419ff102a47dd8fcdf8d51331c428b@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by crockeea): I just got this error with GHC-8.2.2 when profiling with -hr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 20:33:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 20:33:57 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.fa839938a23b3d339d6878545847d414@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I just hit this bug on x86_64 with GHC-8.2.2. It's a large program, so I can't provide an example, but this is still a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 21:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 21:17:23 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.fe68951bc7445946ea79f44c51e6d4fa@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556 Wiki Page: | -----------------------------------+---------------------------------- Comment (by varosi): Isn't it better if GHC could try to dynamically load this library (for -threaded) and if it didn't succeeded to fall back to non-NUMA at runtime? If software have to be distributed in binary form now it should have twice more versions for non-NUMA and for NUMA machines depending of what machine have the user. The same for GHC, now it should have non-NUMA and NUMA versions to be downloaded on haskell.org. Which is not good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 21:49:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 21:49:12 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.a9d1a3c3a04a082e35561e09e7dc4318@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:13 simonpj]: Expanding the `DEFAULT` case before recombining the alts is an interesting idea. I'm wondering though if we'd recreate alts that may have been excluded (by the programmer or optimization steps) based on information that isn't available in `CSE`. At worst we'd still just recreate the same `DEFAULT` alt, so I believe no pessimisation is possible. The design I currently have in mind involves largely imitating `SimplUtils.prepareAlts` to 1. detect which constructors are impossible and should not be considered when expanding the `DEFAULT`. 2. use a variant of `refineDefaultAlt` to expand the `DEFAULT` alt into alts using the remaining possible constructors. Does this sound right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 22:15:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 22:15:06 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.753b5db3ef0a268a2da819e10d5e6b99@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by RyanGlScott): crockeea, GHC 8.4.1 was the first release to incorporate the changes from Phab:D3967. Can you still reproduce the issue with that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 22:23:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 22:23:13 -0000 Subject: [GHC] #14993: QuantifiedConstraints and principal types In-Reply-To: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> References: <051.72a398a0647cda8c2a6914ef278a5255@haskell.org> Message-ID: <066.194944a6dcf636a53a7e05ade7393a43@haskell.org> #14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Replying to [comment:7 simonpj]: > a separate "constraint solver" including implication constraints. Thanks Simon. JFP06 ''Understanding FunDeps via Constraint Handling Rules'' is where the theoretical groundwork was laid, but there was no corresponding development at that time, AFAICT. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 4 22:35:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Apr 2018 22:35:19 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.afc1f0010cbfd8931f3e1230719420c4@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by crockeea): @RyanGlScott: Unfortunately, the program I'm trying to profile depends on #15002. In reality, I ran into this bug with 8.2.2 first, then upgraded to 8.4.1 to see if this bug was fixed there, but ran into #15002 instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 00:16:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 00:16:41 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.7190e32dbd86722bc4871d74b26b6cfd@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: nomeata (added) Comment: This regression was introduced in 0e953da147c405648356f75ee67eda044fffad49 (Implement a dedicated exitfication pass #14152). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 01:09:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 01:09:07 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.a94a15741ece26fe57f6de29854ff6b4@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the bisecting and minimization! Exemplary bug reporting! Judging from the report and the fact that profiling is necessary, it looks like profiling breaks the invariant that a joint point has `Lam`s as their right-hand-side. This can be confirmed by extending the `pprPanic` in `collectNBinders` to also show `orig_expr`. It might just be a case of looking through `Tick`s … but I am no expert on how profiled GHC is supposed to be handled. I am building the current `master` to look into it, but I don’t expect the build to finish in time to actually do that today. Unless someone beats me to it, I’ll have a lock tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 04:06:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 04:06:56 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions Message-ID: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lots of functions in `Data.List` have overtly obvious complexity, like `delete`. It would still be nice to list all the complexities explicitly, especially for beginners. Also, just to set a good example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 04:11:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 04:11:13 -0000 Subject: [GHC] #11815: Data.List: Add a function to get consecutive elements (mapConsecutives) In-Reply-To: <047.a500f487fe67f459851db750fa12afab@haskell.org> References: <047.a500f487fe67f459851db750fa12afab@haskell.org> Message-ID: <062.c204bbdfddac55bd5a55c737f5b174c7@haskell.org> #11815: Data.List: Add a function to get consecutive elements (mapConsecutives) -------------------------------------+------------------------------------- Reporter: holmisen | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gbaz): Should this be closed since the proposal met a negative vote? https://mail.haskell.org/pipermail/libraries/2016-June/027072.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 05:17:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 05:17:15 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.9d1798d1e3cd33649a17522bb0533dd4@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: osa1 Type: bug | Status: closed Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11547 | Differential Rev(s): Phab:D4478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Revert Phab:D2447 made the ticket:11547 existed in HEAD again. See also ticket:14996#comment:2. Perhaps we should implement the conclusion posted in comment:10 ? If so, I'm volunteer to give that a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 05:17:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 05:17:29 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.2fc79b089f2005166ab688bf64c6a1cc@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:2 monoidal]: > Another issue is this: > > {{{ > :1:1: error: > GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer > tcl_env of environment: [] > }}} > > (giving "1" twice is needed to reproduce the error) I think it's just a variant of ticket:11547, since the patch Phab:D2447 has been reverted in ticket:14052. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 05:33:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 05:33:43 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.9d7843262a1793d3bd7c3986fefea5e4@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: osa1 Type: bug | Status: closed Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11547 | Differential Rev(s): Phab:D4478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The conclusion was to not keep shadowed variables at all (because there's no reason for it), whether it's fast or slow. So really the fix for #11547 is just a better error message (as mentioned in comment:22). sighingnow, would you be willing to open a new ticket for that and give it a try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 05:36:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 05:36:42 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.cc79251c91a259a43a148fa65dacae2b@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypedHoles Operating System: 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 error in comment:2 is a different issue than the performance issue so we should deal with it in another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 05:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 05:54:03 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.92f93d279e8df44a2d1eff4c4bd4e70f@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 06:20:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 06:20:26 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.cddcf431d7aa506d31bd7e4946da95d3@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * keywords: profiling osx => profiling * version: 7.4.2 => 8.5 * differential: => Phab:D4567 Old description: > Running the attached program, compiled with "-threaded -Wall -auto-all > -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls" - with the > following flags: +RTS -hc -hbdrag,void -RTS > > The output is as follows: > {{{ > leaks: internal error: Invalid object in processHeapClosureForDead(): 60 > (GHC version 7.4.2 for i386_apple_darwin) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort trap: 6 > }}} New description: Running the attached program, compiled with `-threaded -Wall -auto-all -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls` - with the following flags: `+RTS -hc -hbdrag,void -RTS` The output is as follows: {{{ leaks: internal error: Invalid object in processHeapClosureForDead(): 60 (GHC version 7.4.2 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 06:20:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 06:20:34 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.05a894034af4508bdee99e8b16b0903f@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 06:22:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 06:22:42 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.43f4a1827185fbef1512bc83cd809e53@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We should either stop allocating `CONSTR_NOCAF` on the heap, or apply the patch I submitted. If I'm understanding the story correctly we can legitimately allocate `CONSTR_NOCAF` on the heap so I think the patch is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 07:14:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 07:14:49 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.340c2b8df7e5199f9cace9b7e0d2d5d8@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very good. I suggest that a join-point binding of arity N should always have its lambdas at the top. If there are any ticks involved, they should be inside the N binders. (There may be more than, in which case the normal rules should apply after that.) Moreover, Lint should check this invariant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:01:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:01:22 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.b50a017ea92e8a1e6a735f1add724390@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:13 simonpj]: > Yes, delete the `eqType` branches in both `pushCoTyArg` and `pushValArg`. Leave a Note to say "don't do `eqType` here! (see Trac #14737)". Patch here: https://phabricator.haskell.org/D4568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:02:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:02:10 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.99b465dd1edaf506929679d1a3f0bcd6@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Changes (by tdammers): * differential: Phab:D4385 => Phab:D4385 Phab:D4568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:13:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:13:11 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.dc503788ee8eb78516c42f89c77646df@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by simonpj): I have commented on D4568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:18:25 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.1c342064f072a30acdcaa9f5ef295917@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm wondering though if we'd recreate alts that may have been excluded (by the programmer or optimization steps) based on information that isn't available in CSE. Good point. Let's not be over-elaborate. My suggestion: * Try doing it all in `CSE.combineAlts`, as you suggest in comment:9 * Switch off `combineIdenticalAlts` altogether * Do not try the clever stuff suggested in comment:13 for the reasons you mention If we can get away with doing this only in CSE, that'd be an advantage, I think. Less duplication of effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:30:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:30:10 -0000 Subject: [GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies. Message-ID: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> #15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There seem to be some missing dependencies. {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy- safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist- install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic- too -c libraries/ghc-prim/./GHC/Magic.hs -o libraries/ghc-prim/dist- install/build/GHC/Magic.o -dyno libraries/ghc-prim/dist- install/build/GHC/Magic.dyn_o libraries/base/GHC/IO.hs-boot:9:12: error: • Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp-1.0.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. • In the type signature: mplusIO :: IO a -> IO a -> IO a | 9 | mplusIO :: IO a -> IO a -> IO a | ^^^^^^^^^^^^^^^^^^^^ }}} It seems Magic.hs depends in integer-gmp. Which happened to be not yet built so it fails. I'm not sure which import it is that is missing but recording it here. Commit for head is 72b5f649ede82ab3bb429aa72ee1c572f415b0eb Building single threaded for a while and then continuing the build with -j3 seems to be a valid workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 10:34:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 10:34:50 -0000 Subject: [GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies. In-Reply-To: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> References: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> Message-ID: <062.83118591d8661addc23e6459297eeae3@haskell.org> #15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 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:D4560 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4560 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 12:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 12:45:15 -0000 Subject: [GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies. In-Reply-To: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> References: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> Message-ID: <062.b7112c74dd99b9730846dd30df3b264a@haskell.org> #15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 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:D4560 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Relevant `ghc-devs` thread: https://www.mail-archive.com/ghc- devs at haskell.org/msg15305.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:15:27 -0000 Subject: [GHC] #14713: GHCi doesn't load project. In-Reply-To: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> References: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> Message-ID: <069.1187d5118c6764cd284a6c9a2e36596e@haskell.org> #14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): You can clone the project here: https://github.com/amnh/pcg To replicate run: $ stack build && stack ghci The project is so large I have no idea where the code inducing this the defect might lie. It compiles fine, but I haven't been able to use the GHCi interpreter for over a year. Getting pretty annoying at this point. Seriously hampers prototyping new functionality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:35:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:35:54 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.48c73ee76ea0cdd31fdb6035872c02b1@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => nomeata Comment: > Moreover, Lint should check this invariant. It already does! (`lintRhs`) which is confusing me. Might be a bug in Exitification after all. Will investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:50:24 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.88315e72891fccc41a97adadc3de1dab@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, I see, when you run this with `-dcore-lint`, then the real culprit is found: CSE. Exitification is just where the bug surfaces without lint (phew :-)). Ryan, if it is just a matter of running a script again, would you mind bisecting again with `-dcore-lint`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:54:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:54:44 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.bfba431682e095e7e56f3df3d8b180c8@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:4571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:4571 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:56:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:56:51 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.6325670e47947df2bb5dacbadf26219d@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): nomeata, FWIW, I cannot reproduce either a panic or a Core Lint error on the commit prior to 0e953da147c405648356f75ee67eda044fffad49. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 13:58:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 13:58:39 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.afd34340840108867634a4898269737b@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ok, this means that Exitification is creating the (probably legal) code that CSE then stumbles over. Strangely, CSE is not supposed to CSE join points… Anyways, I am on it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 14:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 14:05:44 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.4a566fd4638ea92280402ab64a03e744@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:4571 => Phab:D4571 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 14:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 14:05:51 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.d10648f87b709fd1ae00d7c072a3e5c6@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D4572 Comment: I found a way of fixing it, submitted for review at Phab:D4572, and also pushed to `wip/T15002` to see if it has performance impact. This simply does less CSE around join points, and I don’t know all the implications, so it may be deemed too crude. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 14:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 14:17:59 -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: <046.d3096c43bf101ad7c81045eb41e2848f@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 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): * Attachment "nofib-table-all.txt" removed. NoFib results of running the diff where we make `catch#` strict in its first argument (no validate run yet) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 14:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 14:17:59 -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.e89f21662a1f92d77ca4ae3447f4f18a@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 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): * Attachment "nofib-table-all.txt" added. Addendum to comment:4: My docker setup was indeed messed up in that it didn't apply any diffs to the GHC checkout. I fixed that and this is the new nofib report. Although some numbers changed, this doesn't change the conclusion we made about item 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 15:25:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 15:25:21 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.bf45db1bb2b8d3f653e3569af4db2261@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Should we back out the D4417 until we can fix this, @michalt? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 16:09:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 16:09:56 -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.28f7646cf83bfc54e668dc89ff673a7d@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 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): * Attachment "catchException.txt" added. Results for Item 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 16:14:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 16:14: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.90b1ecc51c1a8a09aebb32801ccccc18@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Re Item 2: A net loss (0.2% Allocs, 0.1% Instr). `reverse-complement` allocates 11.6% more, `sphere` executes 4.4% more instructions, `binary- trees` 0.9% less. This was the diff: {{{ diff --git a/libraries/base/GHC/IO.hs b/libraries/base/GHC/IO.hs index 118ebea..554b4e3 100644 --- a/libraries/base/GHC/IO.hs +++ b/libraries/base/GHC/IO.hs @@ -142,7 +142,7 @@ have to work around that in the definition of catch below). -- @catchException undefined b == _|_ at . See #exceptions_and_strictness# -- for details. catchException :: Exception e => IO a -> (e -> IO a) -> IO a -catchException !io handler = catch io handler +catchException io handler = catch io handler -- | This is the simplest of the exception-catching functions. It -- takes a single argument, runs it, and if an exception is raised @@ -194,7 +194,7 @@ catch (IO io) handler = IO $ catch# io handler' -- @catchAny undefined b == _|_ at . See #exceptions_and_strictness# for -- details. catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a -catchAny !(IO io) handler = IO $ catch# io handler' +catchAny (IO io) handler = IO $ catch# io handler' where handler' (SomeException e) = unIO (handler e) -- Using catchException here means that if `m` throws an }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 16:15:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 16:15:07 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.aada7bd913bc2e19951b488707b7c718@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have commented, but you won't be notified because the Phab upgrade has made Phab worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 16:17:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 16:17:13 -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.c9e9f2f562e4b793b3fb9a1821f9f072@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 Operating System: 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): > reverse-complement allocates 11.6% more That's remarkable. I expected it to be virtually nothing. I suppose that some investigation is called for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 17:43:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 17:43:57 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.9ea11fcefbf147ac2ce945127f8a710f@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I have updated Phab:D4572 and commented, but you won't be notified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 19:53:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 19:53:11 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.d039443d223f9b354d882eec9000c9ad@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Solve this: [https://gist.github.com/Icelandjack/93cf64878e286ed6378adf8fc0e7c200 gist] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 20:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 20:46:01 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2315005=3A_GHC_fails_with_=E2=80=9CStgCmmEn?= =?utf-8?q?v=3A_variable_not_found=E2=80=9D_when_trying_to_compil?= =?utf-8?q?e_order-maintenance-0=2E2=2E1=2E0?= Message-ID: <046.af15ef1093894b502a607404865aa94e@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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: -------------------------------------+------------------------------------- When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows: {{{ [ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order- maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o ) [ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order- maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): StgCmmEnv: variable not found x_a46z local binds for: $tc'Label $tcLabel $tc'Cell $tcCell $trModule $tc'Cell1 $tc'Cell2 $tc'Cell3 $trModule1 $trModule2 $trModule3 $trModule4 $tc'Label1 $tc'Label2 $tc'Label3 $tcCell1 $tcCell2 $tcLabel1 $tcLabel2 lvl_r4UD lvl1_r4UE lvl2_r4UF lvl3_r4UG lvl4_r4UH lvl5_r4UI lvl6_r4UJ lvl7_r4UK lvl8_r4UL lvl9_r4UM lvl10_r4UN lvl11_r4UO lvl12_r4UP lvl13_r4UQ lvl14_r4UR lvl15_r4US lvl16_r4UT lvl17_r4UU $krep_r4UV $krep1_r4UW $krep2_r4UX lvl18_r4UY $krep3_r4UZ $krep4_r4V0 $krep5_r4V1 $krep6_r4V2 $krep7_r4V3 $krep8_r4V4 $krep9_r4V5 lvl19_r4V6 lvl20_r4V7 lvl21_r4V8 lvl22_r4V9 lvl23_r4Va lvl24_r4Vb lvl25_r4Vc ww_s4W2 lwild_s4W3 lwild1_s4W4 noOfLabels_s4W5 noOfLabels1_s4W6 labelMask_s4W7 $wnewAfterCell_s4Wa ww1_s4Wb ipv1_s4Wf wild_s4Wg ds_s4Wh ds2_s4Wi ww2_s4Wk ww3_s4Wl ww4_s4Wn ww5_s4Wo wild1_s4Wq smallGap_s4Wr wild2_s4Ws Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same problem exists with GHC 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 20:50:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 20:50:40 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.f3afcfeb0b3932e46c46d01a1cb5992a@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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 sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 21:05:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 21:05:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.634c99f5e5861ec8a2af64ed944f5a48@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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 sjakobi): * Attachment "T15005.hs" added. One-file repro -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 21:07:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 21:07:09 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.54dd10413b0bd21b92e842eb86b163cb@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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 sjakobi): I can reproduce the panic when compiling the attached file with `-O1` or `-O2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 21:30:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 21:30:55 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.c76edeabe3252f0e95d91320b6746e8c@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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 jeltsch): No problems with GHC 8.2.2, by the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 21:36:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 21:36:24 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.6bbc258e8dc30da7bff7cc3d80aff332@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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 sjakobi): I cannot reproduce the panic with ghc-HEAD (`c2f90c84e`) or ghc v8.5.20180306 from hvr's PPA. It is interesting (but possibly unrelated) that the testsuite for `order- maintenance` fails when built with ghc-HEAD. With ghc-8.2.2 it passes. {{{ ~/tmp/order-maintenance-0.2.1.0 $ cabal new-test -w ~/src/ghc/inplace/bin /ghc-stage2 -O1 --allow-newer Build profile: -w ghc-8.5.20180402 -O1 In order, the following will be built (use -v for more details): - order-maintenance-0.2.1.0 (test:tests) (first run) Preprocessing test suite 'tests' for order-maintenance-0.2.1.0.. Building test suite 'tests' for order-maintenance-0.2.1.0.. [1 of 1] Compiling Main ( /home/simon/tmp/order- maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.5.20180402 /order-maintenance-0.2.1.0/t/tests/build/testsStub/testsStub- tmp/testsStub.hs, /home/simon/tmp/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.5.20180402/order- maintenance-0.2.1.0/t/tests/build/testsStub/testsStub-tmp/Main.o ) Linking /home/simon/tmp/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.5.20180402/order- maintenance-0.2.1.0/t/tests/build/testsStub/testsStub ... Running 1 test suites... Test suite tests: RUNNING... Test case Dumb vs. Dietz and Sleator O(log n) amortized time: Fail "(after 14 tests and 5 shrinks):Exception: Map.!: given key is not an element in the map CallStack (from HasCallStack): error, called at libraries/containers/Data/Map/Internal.hs:610:17 in containers-0.5.11.0:Data.Map.InternalnewMinimum -> x_1, newAfter x_1 -> x_2, newMinimum -> x_3, newBefore x_2 -> x_4, newAfter x_4 -> x_5, delete x_1, newBefore x_1 -> x_7" Test suite tests: FAIL ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 23:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 23:03:40 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.8e9df1a6c51ab32d30652b66f8fd7a3a@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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): Some notes: * This bug was introduced in commit 0e953da147c405648356f75ee67eda044fffad49 (Implement a dedicated exitfication pass #14152) * This bug later disappeared after commit 06366890ba77c20198d7fccc870083b0bbfb1b11 (Fix the lone-variable case in callSiteInline) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 5 23:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Apr 2018 23:40:27 -0000 Subject: [GHC] #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias In-Reply-To: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> References: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> Message-ID: <066.73c91d12f8904444eeb1c24284dfe8bb@haskell.org> #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): For context this was to encode [https://hackage.haskell.org/package/kan- extensions-5.1/docs/Data-Functor-Yoneda.html Yoneda ((->) a) b] with constraints {{{#!hs newtype Yoneda f b = Yoneda (forall xx. (b -> xx) -> f xx) type Yo a b = Yoneda ((->) a) b lower :: forall a b. (Yo a b) -> (a -> b) lower (Yoneda yoneda) = yoneda (id @b) lift :: (a -> b) -> (Yo a b) lift f = Yoneda (. f) }}} ---- Replying to [comment:1 simonpj]: > Iceland Jack! You are torturing me. Think of it as enhanced bug reporting In this particular case the fluke does a good thing, it behaves like the `lower` function where instead of applying to the identity function `(id @b)` the constraint solver conjures up the identity constraint `(Implies b b)`. > If we expanded more vigorously, the fluke would happen both times. I'm not sure how hard to work on this. I'm ok with the looping situation. Would the hypothetical change make `Implies` behave more like `=>`? Making them substitutable ''may'' be a desirable property That being said! The current implementation is very impressive. If something seem unworkable there is surprisingly often some way to guide (trick) GHC into accepting it ([https://gist.github.com/Icelandjack/aeda8e98214cc52c96230af7b8724d25 quantifying over TFs], [https://ghc.haskell.org/trac/ghc/ticket/14878#comment:2 overlap], [https://gist.github.com/Icelandjack/93cf64878e286ed6378adf8fc0e7c200 overlap]). I hope that doesn't change :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 00:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 00:06:19 -0000 Subject: [GHC] #5129: "evaluate" optimized away In-Reply-To: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> References: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> Message-ID: <058.deaf4b31c2543dd2b449c127fd862c02@haskell.org> #5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by George): Forgive me for asking what seems to be obvious: do we need to run validate ./slow more often? Maybe we have already decided to do that in which case it might be good to record that here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 00:07:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 00:07:06 -0000 Subject: [GHC] #5129: "evaluate" optimized away In-Reply-To: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> References: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> Message-ID: <058.2c4df30e06c875da5b75b4d504a6e3a9@haskell.org> #5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 04:51:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 04:51:23 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down Message-ID: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The user guide is linking to cdn.mathjax.org to load mathjax, but it has shut down since last year. https://www.mathjax.org/cdn-shutting-down/ For example, the "\(I\)" are not being rendered: > Find all instances \(I\) that match the target constraint; that is, the target constraint is a substitution instance of \(I\). These instance declarations are the candidates. https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/glasgow_exts.html #instance-overlap -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 07:19:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 07:19:56 -0000 Subject: [GHC] #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias In-Reply-To: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> References: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> Message-ID: <066.45737128c20b3e2e2276196b62712a16@haskell.org> #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): > The current implementation is very impressive. If something seem unworkable there is surprisingly often some way to guide (trick) GHC into accepting it Well that is good news, thanks. I hope you are going to write a paper to explain the uses of quantified constraints; and in there we can explore the boundaries and he way to guide GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 07:48:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 07:48:22 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.dfef2c985e0669b4480c42791b547aed@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Joachim, I've just been looking at `Exitify.hs` in pursuit of #15005. It's not easy going. Could you add some careful Notes? For example, here are the things I stumbled over immediately: * In the top-level `exitifyProgram` I think we make no attempt to exitify top level recursive functions. That's fine, but say so. * Then in `go` of `exitifyProgram` I think we are looking at the RHS of a top-level function, and applying `goBind` to every binding within it. (NB: `goBind` calls `go` to deal with the RHS of the bindings; I'd be inlined do that in `go` so that `goBind` gets the post-exitify bindings.) * Mysteriously we do not exitify the RHS of a case alternative (`goAlts`). This exception seems highly mysterious, possibly a bug? * Then for recursive join-point bindings, we apply `exitify` to them (after having recursively processed the RHSs). * There is some magic in `go` in `exitify` to pick out the ones we want to exitify. Explaining these conditions in a note would be good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:02:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:02:57 -0000 Subject: [GHC] #12949: Pattern coverage checker ignores dictionary arguments In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.b747d0b79a291c4c76dad649a4147bae@haskell.org> #12949: Pattern coverage checker ignores dictionary arguments -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Hello, I'm working on this ticket and now I can tell what's going wrong with the case in comment:11. I think I need some help to go further and submit the patch. Look at the example in comment:11: {{{#!hs q :: forall a b . (Foo a, Foo b) => Result a b q = case foo :: Maybe a of Nothing -> case foo :: Maybe b of Nothing -> Neither Just c -> That c }}} When do `checkMatches` on inner `case` statement, we first call `mkInitialUncovered` to set up a NameEnv, in this function we use `getTmCsDs` to obtain the initial name env, we have {{{#!hs [(ds_d14i, foo), (ds_d14h, Nothing), (ds_d14h, foo)] }}} Nothing that these two `foo` have different `Id` (type), but the same `Name`. We then translate them as `ComplexEq`, only keeping the `Name` in `PmExprVar`. Then we get the `initTmState`. In `ConVar` case of `pmcheckHd`, we have ComplexEq `(ds_d14i, Just $pm_d14m)` and use `solveOneEq` to decide whether it is a valid candidate `PmCon`. In `solveOneEq`, we first do deep substitution by looking up the `Name` of `PmExprVar` from env. Now `ds_d14i` is replaced with `foo` and further replaced with `Nothing`, then `solveOneEq` fails and the `Just` pattern is redundant. --------------------------------------------- To solve this, we need to consider both name and type of variables when do substitution. In comment:7 gkaracha proposed that > Turning Name back into Id in the checker Should we move from `PmExprVar Name` to `PmExprVar Id` ? In `varDeepLookup`, when find the `PmExpr` from PrVarEnv, we could first check it's type then do further substitution. Do that make sense ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:11:56 -0000 Subject: [GHC] #898: GHC compiles against Apple's readline, giving error In-Reply-To: <046.e19c4b1e220092591822b9e0f05cfc1d@haskell.org> References: <046.e19c4b1e220092591822b9e0f05cfc1d@haskell.org> Message-ID: <061.b1556e377ea7d8c2a3a770bded90aa52@haskell.org> #898: GHC compiles against Apple's readline, giving error ---------------------------------+----------------------------------- Reporter: doaitse | Owner: thorkilnaur Type: bug | Status: closed Priority: high | Milestone: 6.6.1 Component: Build System | Version: 6.5 Resolution: invalid | Keywords: OSX Sockets Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------------- Changes (by ulysses4ever): * keywords: "OS X" Sockets => OSX Sockets * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:12:35 -0000 Subject: [GHC] #1013: interpretBCO: unknown or unimplemented opcode 64356 In-Reply-To: <043.b7a9369cedc709aa64a45d9402069456@haskell.org> References: <043.b7a9369cedc709aa64a45d9402069456@haskell.org> Message-ID: <058.0ff484dda13f83ae87d5e7f63ac5e438@haskell.org> #1013: interpretBCO: unknown or unimplemented opcode 64356 -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Resolution: fixed | Keywords: OSX Sockets Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghci002 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * keywords: "OS X" Sockets => OSX Sockets * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:15:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:15:07 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.325ff3acdaac0404ca9555bcbbc1ee49@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Isn't the `isOneOcc` redundant? All join-point should have `OneOcc`. Maybe it'd be clearer to say {{{ isExitJoinId id | isJoinId id = case idOccInfo id of IAmDead -> False IAmALoopBreaker {} -> False -- A joinrec is never an exit join-ids OneOcc { occ_in_lam = in_lam } -> in_lam ManyOccs {} -> pprPanic "isExitJoinId" id | otherwise = False }}} Also I'd put this function in `SimplUtils` or something. Occurrence info is only valid on `InIds`, so it's crucial that `isExitJoinId` is only called on freshly occ-analysed code. It's not a generic function you can call anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:16:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:16:33 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.7f6428fa3d23134360a5bbe98074711d@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What's this (in `Exitify`): {{{ where exit_id_tmpl = mkSysLocal (fsLit "exit") initExitJoinUnique ty `asJoinId` join_arity `setIdOccInfo` exit_occ_info -- See Note [Do not inline exit join points] exit_occ_info = OneOcc { occ_in_lam = True , occ_one_br = True , occ_int_cxt = False , occ_tail = AlwaysTailCalled join_arity } }}} The occurrence analyser sets occ-info. No one else should. What happens if you leave this out? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:24:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:24:12 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker Message-ID: <049.2656489ff85910f6a80bbfa971643315@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11547 #14052 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ticket:14052, we reverted Phab:D2447, then ticket:11547 exists in HEAD again. In ticket:14052#comment:25 and ticket:14052#comment:10, we decide that shadowed variables shouldn't be keep at all. This ticket is created to track the idea. The same error of ticket:11547 was also reported in ticket:14996#comment:2, > {{{#!hs > $ inplace/bin/ghc-stage2 --interactive > GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help > Prelude> 1 > 1 > Prelude> 1 > 1 > Prelude> _ > > :1:1: error: > GHC internal error: ‘Ghci1.it’ is not in scope during type > checking, but it passed the renamer > tcl_env of environment: [] >}}} > > (giving "1" twice is needed to reproduce the error) NB: input "1" twice to create shadowed context is necessary to reproduce this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:24:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:24:23 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.f1bb392e4c28af1d6b2dfa03ee4b440f@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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: #11547 #14052 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:33:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:33:37 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.286d6cc68639e2bf1dceb648baefa5cb@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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): The bug is in this line of `Exitify` {{{ -- The possible arguments of this exit join point args = filter (`elemVarSet` fvs) captured }}} You have to do at least `map zapStableUnfolding` over args. Consider {{{ joinrec j x = let {-# INLINE foo #-} foo y = blah in case x of True -> j2 foo (h x) False -> ...j.... }}} We are going to exitify the True branch of the 'case x'. But 'foo' is captured, so we get {{{ join exit foo x = jump j2 foo (h x) in joinrec j x = let {-# INLINE foo #-} foo y = blah in case x of True -> jump exit foo x False -> ...j.... }}} But we must zap `foo`'s unfolding when we lambda-abstract it! In effect, the lambda-bound `foo` is an entirely new `foo`, unrelated to the original. Actually, arguably we should give the lambda-bound foo `vanillaIdInfo`. We do this in `SetLevels.abstractVars`. I think that'd be safer. We don't seem to have a function `zapAllIdInfo` but we probably should. Over to you. Please include some version of this explanation, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 08:42:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 08:42:14 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.3f5f6870f6fe06b42fc38939182d208f@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I ''really'' don't want to add new annotations! Would it be possible to distil out a small example of what goes wrong with `integer`? It may not be fixable, but it's always worth a try. I suppose the gain here is important... it's a fairly common case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:00:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:00:43 -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.d87acd8ac50e7aff639db5af5b7df4fc@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 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): * Attachment "catchRetry.txt" added. NoFib results for item 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:05:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:05:48 -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.f19637e65c1a473c4a2a4af8e1dc908e@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): The diff I used for item 1: {{{ diff --git a/compiler/prelude/primops.txt.pp b/compiler/prelude/primops.txt.pp index 1362704074..4c65ba4220 100644 --- a/compiler/prelude/primops.txt.pp +++ b/compiler/prelude/primops.txt.pp @@ -2377,7 +2377,7 @@ primop CatchRetryOp "catchRetry#" GenPrimOp -> (State# RealWorld -> (# State# RealWorld, a #) ) -> (State# RealWorld -> (# State# RealWorld, a #) ) with - strictness = { \ _arity -> mkClosedStrictSig [ catchArgDmd + strictness = { \ _arity -> mkClosedStrictSig [ lazyApply1Dmd , lazyApply1Dmd , topDmd ] topRes } -- See Note [Strictness for mask/unmask/catch] }}} No change in allocations, max +0.1% in counted instructions for `scc`. I have yet to run a validate, but this seems worthwhile if it would get rid of `ExnStr`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:10:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:10:09 -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.eb94def162b2d517aa784d85daaf235f@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 Operating System: 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): That's good. It'd be a big win. And we have no justification for treating `catchRetry#` specially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:21:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:21:09 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.b7f2c5e9bca6c69277df6ba571fa531a@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also in `Exitify`: {{{ -- We cannot abstract over join points captures_join_points = any isJoinId args }}} Isn't this vacuously false? Join points are never arguments -- or they would not be join points! Ah, no... `args` is (confusingly) not the argument of the call (although you use `args` for this purpose in the `collectArgs` call...aargh. Can we rename `args` to `abs_vars`, the variables over which we are going to abstract? Ah! You probably need to topologically sort those `abs_vars`; see the `sortQuantVars` call in `SetLevels.abstractVars`. A bug waiting to happen. Returning to `captures_join_points` this can only be true of a call of form `j e1 .. en`, which you deal with in an earlier case... so the test would better be done there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:24:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:24:04 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.ade62d5a27bdfed3cda19fe7c399255a@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider {{{ joinrec j x y z = case x of True -> False -> ...j... }}} where `` does not mention `j`. It looks to me that you don't even attempt to turn the whole of `` into an exit point. Instead you recurse into it. But why don't you? The bigger the better! {{{ join exit y = in joinrec j x y z = case x of True -> exit y False -> ...j... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:48:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:48:09 -0000 Subject: [GHC] #14951: SpecConstr needs two runs when one should suffice In-Reply-To: <046.2335cd5876de5516a20812036c470d04@haskell.org> References: <046.2335cd5876de5516a20812036c470d04@haskell.org> Message-ID: <061.49b9ae0ef04639c41d69cb20572436db@haskell.org> #14951: SpecConstr needs two runs when one should suffice -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14844 | Differential Rev(s): Phab:D4519 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): !SpecConstr is already trying quite hard to be idempotent, but it is manifestly failing. It would be extremely helpful to distil poster-child examples of when it's not idempotent. `mandel2` is a good starting point because it has a very small kernel. It's also a surprise that the best instruction count improvements seem unrelated to the allocations! I don't know what to make of that. We need more insight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 09:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 09:57:38 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down In-Reply-To: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> References: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> Message-ID: <059.9e4517c748ba746db397226a78abfec1@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Seems that Sphinx switched CDN [https://github.com/sphinx- doc/sphinx/issues/3599 since 1.5.5]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 11:56:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 11:56: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.2a6187aa2df5e3b2dd1f92b3aa2abcad@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:7 simonpj]: > > reverse-complement allocates 11.6% more > > That's remarkable. I expected it to be virtually nothing. I suppose that some investigation is called for. Long story short, there was no difference in generated Core for both `reverse-complement` and `sphere`. The difference is is due to the [https://hackage.haskell.org/package/base-4.11.0.0/docs/src/GHC.IO.Handle.Internals.html#do_operation do_operation function] that has a call to `catchException`. When I compare the strictness signatures when compiling `GHC.IO.Handle.Internal` there is a notable difference for the `withHandle*` family of functions which calls `do_operation`: {{{ 36,38c36,38 < GHC.IO.Handle.Internals.withAllHandles__: < GHC.IO.Handle.Internals.withHandle: < GHC.IO.Handle.Internals.withHandle': --- > GHC.IO.Handle.Internals.withAllHandles__: > GHC.IO.Handle.Internals.withHandle: > GHC.IO.Handle.Internals.withHandle': 41c41 < GHC.IO.Handle.Internals.withHandle__': --- > GHC.IO.Handle.Internals.withHandle__': 80,82c80,82 < GHC.IO.Handle.Internals.withAllHandles__: < GHC.IO.Handle.Internals.withHandle: < GHC.IO.Handle.Internals.withHandle': --- > GHC.IO.Handle.Internals.withAllHandles__: > GHC.IO.Handle.Internals.withHandle: > GHC.IO.Handle.Internals.withHandle': 85c85 < GHC.IO.Handle.Internals.withHandle__': --- > GHC.IO.Handle.Internals.withHandle__': }}} These are called transitively by `hGetBuf` and `hPutBuf`. We could annotate the IO action passed to `do_operation` for an easy fix: {{{ diff --git a/libraries/base/GHC/IO/Handle/Internals.hs b/libraries/base/GHC/IO/Handle/Internals.hs index 48ece1dc5e..3d58f3d3bc 100644 --- a/libraries/base/GHC/IO/Handle/Internals.hs +++ b/libraries/base/GHC/IO/Handle/Internals.hs @@ -163,7 +163,8 @@ do_operation :: String -> Handle -> (Handle__ -> IO a) -> MVar Handle__ -> IO a do_operation fun h act m = do h_ <- takeMVar m checkHandleInvariants h_ - act h_ `catchException` handler h_ + let !io = act h_ + io `catchException` handler h_ where handler h_ e = do putMVar m h_ }}} I'm not sure if that's just navigating around the problem, but this brings strictness signatures on par and fixes `sphere` and `reverse-complement`. I'll re-run benchmarks now. Also, without this patch, T12996 (#12996) broke in `./validate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 11:59:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 11:59:11 -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.28a503848ccc0d69d124d46efdc5e71f@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): `./validate` for the `catchRetry#` changes (item 1) found no issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 12:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 12:38:22 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.c68e59fba146b71b2b1d48361c7d488f@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 13:05:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 13:05:26 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.272bfe7c2582472852a35d870197c0aa@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): There was a reddit discussion[1] that reminded me of this, and it got a tangential but related idea going in my mind. I wonder if there's any connection between user-defined functions with a compulsory unfolding and `UNPACK` on polymorphic fields in a data constructor (currently disallowed because they result in code that cannot be compiled). Roughly, the idea was that a compulsory unfolding would be required for functions that target data types with unpacked polymorphic fields. For example: {{{ data Foo a = Foo {-# UNPACK -#} !Int {-# UNPACK #-} !a {-# INLINE MANDATE useFoo #-} useFoo :: Foo a -> a useFoo (Foo _ a) = a }}} This would also lift the restriction on levity-polymorphic fields in a data constructor. There are a bunch of other problems with this that may not be possible to resolve. How does pattern matching actually work with this? How can `Foo Word` be stored inside of another data type? Anyway, I'm not convinced this could actually go anywhere, but I thought I'd jot it down. [1] https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontainers/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 13:24:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 13:24:35 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.72c865e5c3f777d9ab559a2b52df724c@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Type-class specialisation now happens flawlessly across modules. That > is, if I define > {{{ > module DefineF where > f :: Num a => a -> a > {-# INLINEABLE f #-} > f x = ...f x'.... > }}} > then modules that import `DefineF` and call `f` at some particular type > (say `Int`) will generate a specialised copy of `f`'s code. > > But this does not happen for `SpecConstr`; we only specialise a function > for calls made in the same module. All the infrastructure is in place to > allow cross-module `SpecConstr`; it just hasn't been done yet. This > ticket is to record the idea. New description: Type-class specialisation now happens flawlessly across modules. That is, if I define {{{ module DefineF where f :: Num a => a -> a {-# INLINEABLE f #-} f x = ...f x'.... }}} then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code. But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. For example: {{{ module M where {-# INLINABLE foo #-} foo True y = y foo False (a,b) = foo True (a+b,b) module X where import M bar = ...(foo (x,y))... }}} Here `foo` is called with an explicit `(x,y)` argument in module `X`, and we'd like to !SpecConstr it, as it would be if the call was in module `M`. All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 13:33:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 13:33:15 -0000 Subject: [GHC] #14955: Musings on manual type class desugaring In-Reply-To: <049.12855af11ea5950a6983dee948966231@haskell.org> References: <049.12855af11ea5950a6983dee948966231@haskell.org> Message-ID: <064.ef3142752bf36ebe504eb8dc39c33d28@haskell.org> #14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: SpecConstr Operating System: 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): (2) is slow becuase we don't (yet) do cross-module !SpecConstr. If `dors` was `INLINEABLE` then in principle !SpecConstr could specialise it in `Main`, in a similar way to `Specialise`. But that is a whole new thing. (A very good thing, incidentally: that is Trac #10346. (3) jolly well ought to be fast. That's a bug. Here is what is happening. The `INLINABLE` pragma on `pors` (for (3)) or `porsProxy` (for (4)) should arrange that these functions can be speicalised in a separate module. But in fact `pors` is worker/wrappered by the demand analyser! We get this in the .hi file: {{{ pors :: PropProxy r => [r] -> r {- Arity: 2, HasNoCafRefs, Strictness: , Inline: [0], Unfolding: InlineRule (2, True, False) (\ @ r (w :: PropProxy r) (w1 :: [r]) -> case w `cast` (N:PropProxy[0] _N) of ww { PropDict ww1 ww2 ww3 ww4 -> $wpors @ r ww1 ww3 w1 }) -} porsProxy :: PropProxy2 r => [r] -> r {- Arity: 2, HasNoCafRefs, Strictness: , Inline:, Unfolding(loop-breaker): (\ @ r ($dPropProxy2 :: PropProxy2 r) (ds :: [r]) -> case ds of wild { [] -> case propDict2 @ r $dPropProxy2 of wild1 { PropDict ds1 ds2 ds3 ds4 -> ds3 } : o os -> case propDict2 @ r $dPropProxy2 of wild1 { PropDict ds1 ds2 ds3 ds4 -> ds1 o (porsProxy @ r $dPropProxy2 os) } }) -} }}} So `porsProxy` can be specialised in the calling file -- good. And so can `pors` -- but the specialised version of its code is silly, just a call to the un-specialised `$wpors`; still a higher order function, which is bad bad bad. But I fixed this more 6 years ago. See this Note in `WwLib`: {{{ Note [Do not unpack class dictionaries] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If we have f :: Ord a => [a] -> Int -> a {-# INLINABLE f #-} and we worker/wrapper f, we'll get a worker with an INLINABLE pragma (see Note [Worker-wrapper for INLINABLE functions] in WorkWrap), which can still be specialised by the type-class specialiser, something like fw :: Ord a => [a] -> Int# -> a BUT if f is strict in the Ord dictionary, we might unpack it, to get fw :: (a->a->Bool) -> [a] -> Int# -> a and the type-class specialiser can't specialise that. An example is Trac #6056. Moreover, dictionaries can have a lot of fields, so unpacking them can increase closure sizes. Conclusion: don't unpack dictionaries. }}} So why isn't this preventing the w/w for `pors`? Because the bit that prevents the unpacking is here: {{{ deepSplitProductType_maybe fam_envs ty | let (co, ty1) = topNormaliseType_maybe fam_envs ty `orElse` (mkRepReflCo ty, ty) , Just (tc, tc_args) <- splitTyConApp_maybe ty1 , Just con <- isDataProductTyCon_maybe tc , not (isClassTyCon tc) -- See Note [Do not unpack class dictionaries] , let arg_tys = dataConInstArgTys con tc_args strict_marks = dataConRepStrictness con = Just (con, tc_args, zipEqual "dspt" arg_tys strict_marks, co) }}} Ha! We do `topNormaliseType_maybe` before checking `isClassTyCon`. And when the class is a newtype, that `topNormaliseType_maybe` unwraps it. It's easy to fix: just move the test earlier. Patch coming -- but maybe after next week when I'm on holiday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 13:40:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 13:40:28 -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.c135a48fc5dde724d59c238577057816@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 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): * Attachment "catchException.2.txt" added. Results for Item 2 after fixing `do_operation` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 13:41:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 13:41:42 -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.9e31f9a6be0fb2062f3e80d1f2a7d6de@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Item 2 no longer regresses in performance and passes `./validate` with this diff: {{{ diff --git a/libraries/base/GHC/IO.hs b/libraries/base/GHC/IO.hs index 05ad277127..f9dbfef71b 100644 --- a/libraries/base/GHC/IO.hs +++ b/libraries/base/GHC/IO.hs @@ -142,7 +142,7 @@ have to work around that in the definition of catch below). -- @catchException undefined b == _|_ at . See #exceptions_and_strictness# -- for details. catchException :: Exception e => IO a -> (e -> IO a) -> IO a -catchException !io handler = catch io handler +catchException io handler = catch io handler -- | This is the simplest of the exception-catching functions. It -- takes a single argument, runs it, and if an exception is raised @@ -194,7 +194,7 @@ catch (IO io) handler = IO $ catch# io handler' -- @catchAny undefined b == _|_ at . See #exceptions_and_strictness# for -- details. catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a -catchAny !(IO io) handler = IO $ catch# io handler' +catchAny (IO io) handler = IO $ catch# io handler' where handler' (SomeException e) = unIO (handler e) -- Using catchException here means that if `m` throws an diff --git a/libraries/base/GHC/IO/Handle/Internals.hs b/libraries/base/GHC/IO/Handle/Internals.hs index 48ece1dc5e..3d58f3d3bc 100644 --- a/libraries/base/GHC/IO/Handle/Internals.hs +++ b/libraries/base/GHC/IO/Handle/Internals.hs @@ -163,7 +163,8 @@ do_operation :: String -> Handle -> (Handle__ -> IO a) -> MVar Handle__ -> IO a do_operation fun h act m = do h_ <- takeMVar m checkHandleInvariants h_ - act h_ `catchException` handler h_ + let !io = act h_ + io `catchException` handler h_ where handler h_ e = do putMVar m h_ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 14:38:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 14:38:04 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables Message-ID: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.5 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 found myself wanting to write (simplified) {{{ type MyMonad m = (MonadReader r m, Show r) }}} but GHC does not accept this, it wants `r` as part of the type synonym. So why did I think this could work? Because `MonadReader` has a functional dependency: {{{ class Monad m => MonadReader r m | m -> r }}} so if `m` determines `r`, why do I have to write `MyMonad r m` and not just `MyMonad m`? Can I not “hide” the fact that, somewhere internal to the `MyMonad` synonym, there is an additional variable `r` around? Clearly supporting this would need a language proposal, but I wanted to open a ticket here first to hear if this would even be possible to implement. ([https://stackoverflow.com/questions/29686920/is-it-possible-to-have- forgetful-type-synonyms-in-haskell Others have wanted this before as well.]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 15:35:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 15:35:17 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.d01233c041d5d37e4a4b4548c0e9726d@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Wow, thanks for the thorough code review. I am not sure how I go that `goAlts` thing wrong. That ought to cripple the analysis significantly! Maybe part of some late refactoring before the merge? Anyways, I will go through all your comments in detail and implement what I can, maybe this afternoon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 16:37:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 16:37:54 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.3a8ad41e573b9387bd04f7de74a09129@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): I consider this solved by QuantifiedConstraints {{{#!hs a :: (MonadReader r m, Show r) => m String a = fmap show ask }}} becomes {{{#!hs -- A type synonym works but is less useful class (forall xx. (MonadReader xx m, Show xx)) => MyMonad m instance (forall xx. (monadReader xx m, Show xx)) => MyMonad m b :: MyMonad m => m String b = fmap show ask }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 17:04:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 17:04:39 -0000 Subject: [GHC] #11815: Data.List: Add a function to get consecutive elements (mapConsecutives) In-Reply-To: <047.a500f487fe67f459851db750fa12afab@haskell.org> References: <047.a500f487fe67f459851db750fa12afab@haskell.org> Message-ID: <062.5d06106a5221abc53b436da400a7add7@haskell.org> #11815: Data.List: Add a function to get consecutive elements (mapConsecutives) -------------------------------------+------------------------------------- Reporter: holmisen | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by holmisen): I do not know about the process for this, but as the proposer I think there are two ways to move forward; either make another try on the libraries list or closing the ticket. The vote was non conclusive if counting my own vote, but as of now I do not intend to make another go at the libraries list. It would be neat with a name for this function, but with the low interest it might be better to close this ticket so that it does not distract people from other issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 17:11:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 17:11:01 -0000 Subject: [GHC] #15009: Float equalities past local equalities Message-ID: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the two datatypes {{{#!hs data T1 a where MkT1 :: a ~ b => b -> T1 a data T2 a where MkT2 :: a -> T2 a }}} To me, these look like two ways of writing the same thing. Yet they participate quite differently in type inference. If I say {{{#!hs f (MkT1 a) = not a g (MkT2 a) = not a }}} then `g` is accepted (with type `T2 Bool -> Bool`) while `f` is rejected as GHC mutters about untouchable type variables. Of course, GHC's notion of untouchable type variables is a Good Thing, with arguments I won't rehearse here. It all boils down to this rule: (*) Information that arises in the context of an equality constraint cannot force unification of a unification variable born outside that context. I think this rule is a bit too strict, though. I propose a new rule: (%) Information that arises in the context of a ''non-purely-local'' equality constraint cannot force unification of a unification variable born outside that context. where '''Definition:''' An equality constraint is ''purely local'' if every type variable free in the constraint has the same scope as the constraint itself. That is, if an equality constraint mentions only variables freshly brought into scope -- and no others -- then we can still unify outer unification variables. Happy consequences of this choice: * `f` above could be accepted, as the equality in `MkT1` is purely local. * Rule (%) allows users to effectively let-bind type variables, like this: {{{#!hs f :: forall a. (a ~ SOME REALLY LONG TYPE) => Maybe a -> Maybe a -> Either a a }}} Currently, this kind of definition (if it's, say, within a `where` clause) triggers rule (*) in the body of the function, and thus causes type inference to produce a different result than just inlining `SOME REALLY LONG TYPE`. * We could theoretically simplify our treatment of GADTs. Right now, if you say {{{#!hs data G a b c where MkG :: MkG d Int [e] }}} GHC has to cleverly figure out that `d` is a universal variable and that `e` is an existential, producing the following Core: {{{#!hs data G a b c where MkG :: forall d b c. forall e. (b ~ Int, c ~ [e]) => MkG d b c }}} If we use rule (%), then I believe the following Core would behave identically: {{{#!hs data G a b c where MkG :: forall a b c. forall d e. (a ~ d, b ~ Int, c ~ [e]). MkG a b c }}} This treatment is more uniform and easier to implement. (Note that the equality constraints themselves are unboxed, so there's no change in runtime performance.) What are the downsides of (%)? I don't think there are any, save an easy extra line or two in GHC to check for locality. Rule (*) exists because, without it, GHC can infer non-principal types. However, I conjecture that Rule (%) also serves to require inference of only principal types, while being more permissive than Rule (*). I'm curious for your thoughts on this proposal. (I am making it here, as this is really an implementation concern, with no discernible effect on, say, the user manual, although it would allow GHC to accept more programs.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 18:15:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 18:15:06 -0000 Subject: [GHC] #15010: Application (warp) server crashing periodically with "TSO object entered" Message-ID: <047.a86a5c0a290e1c542e4015a537513efc@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We are seeing one of our warp servers periodically crash with the following error: {{{ Apr 06 10:44:28 stdouterr.log: binary-name-elided: internal error: TSO object entered! Apr 06 10:44:28 stdouterr.log: (GHC version 8.0.2 for x86_64_unknown_linux) }}} We are sometimes seeing CPU/memory spikes concurrently with this error, but not always. We are running very similar servers for other applications and they are '''not''' experiencing this error. But this server is one of our highest- load ones. Other tickets I found with this error: * https://ghc.haskell.org/trac/ghc/ticket/12383 * https://ghc.haskell.org/trac/ghc/ticket/8316 But these seem to be happening in ghci and ghc itself, not in a binary compiled by ghc. Questions I have: * What exactly is this error? * Is there anything else we can do on our side to help debug? Any artifacts that should be produced upon crash? * Should we consider upgrading our GHC version from 8.0.2 to get a bugfix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 18:21:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 18:21:00 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.893658590f0037eac80bfc59ebb7d942@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, nice! This answers the question “is it feasible and implementable?”. It still leaves the question “do we want to provide the convenience of a type synonym to our users” so that they don't have to encode it manually using such a class and an instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 18:48:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 18:48:59 -0000 Subject: [GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies. In-Reply-To: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> References: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> Message-ID: <062.c1423683e0f1648e0190388038452b57@haskell.org> #15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 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:D4560 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"54acfbbf64f5fcb108836412e9be0cfabf0d7801/ghc" 54acfbb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="54acfbbf64f5fcb108836412e9be0cfabf0d7801" base: Add dependency on GHC.Integer in a few boot files Summary: The typechecker started trying to pull in GHC.Integer.Type's interface file due to the change made in d8d4266bf73790f65b223ec16f645763eaed8be3. It's unclear why the patch in question changed this behavior, but these typechecker- induced dependencies are known to be a bit fragile and adding these imports ensures that the build order is correct. Test Plan: Validate Reviewers: goldfire, hvr Subscribers: thomie, carter GHC Trac Issues: #15004 Differential Revision: https://phabricator.haskell.org/D4560 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 19:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 19:10:02 -0000 Subject: [GHC] #15004: Building HEAD fails with -j3 because of unrecorded dependencies. In-Reply-To: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> References: <047.203ab619eb3d8afca6aaa64c396c70ea@haskell.org> Message-ID: <062.8ff44583bc9df368e5b245d4da9cc7ba@haskell.org> #15004: Building HEAD fails with -j3 because of unrecorded dependencies. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 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:D4560 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I believe this should be fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 20:48:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 20:48:53 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.89343e8d0b4596d2334266f7b0a71531@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): Did you have something like that in mind? {{{#!hs -- user writes type MyMonad m = (MonadReader r m, Show r) }}} but GHC knows that `r` is determined by `m` so silently {{{#!hs -- GHC transforms it into type MyMonad m = (forall xx. (MonadReader xx m, Show xx)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 20:49:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 20:49:39 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.e0cbd8fc0b3b40f99b16352af1af65db@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 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 Iceland_jack): * keywords: => QuantifiedConstraints, wipT2893 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 21:26:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 21:26:43 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.df69a624947ddde5e2823aebc0f35ab7@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > In the top-level exitifyProgram I think we make no attempt to exitify top level recursive functions. That's fine, but say so. There are no top-level join points. Note that exitification does not make new join points. But I added a one-line comment to remind of this fact. > Then in go of exitifyProgram I think we are looking at the RHS of a top-level function, and applying goBind to every binding within it. (NB: goBind calls go to deal with the RHS of the bindings; I'd be inlined do that in go so that goBind gets the post-exitify bindings.) Not sure I follow the NB. Isn’t it the common idiom to have a `goExpr` (here `go`), and a `goBind` that are mutually recursive? > Mysteriously we do not exitify the RHS of a case alternative (goAlts). This exception seems highly mysterious, possibly a bug? Not mysterious at all: I exitify `joint points`, i.e. recursive binders. The RHS of a case alternative is just an expression – nothing to exitify there. And `goAlts` calls `go` just fine… I am actually not sure what is confusing about `exitifProgram`. Its comment says > `Traverses the AST, simply to find all joinrecs and call 'exitify' on them.` and it does precisely that. > There is some magic in go in exitify to pick out the ones we want to exitify. Explaining these conditions in a note would be good Every of the three conditions has a comment, and the first two point to notes… > Maybe it'd be clearer to say … I'd put this function in `SimplUtils` or something. done > The occurrence analyser sets occ-info. No one else should. What happens if you leave this out? If I leave this out, then until the next run of the occ analyzer, `isExitJoinId` will not detect an exit join point as such. From your clarification about that function I conclude that it shall only be used by the simplifier, which runs the occ analyzer before, so it looks like I can leave this out. Will try. > Can we rename `args` to `abs_vars`, the variables over which we are going to abstract? Of course, sorry for that. > You probably need to topologically sort those `abs_vars` Thanks, done. > Returning to captures_join_points this can only be true of a call of form j e1 .. en I don’t think that’s true. What if I exitify something like {{{ case b of True -> jump j 1; False -> jump j 2 }}} This is not of this form, and I need to check whether I can actually abstract over this? > It looks to me that you don't even attempt to turn the whole of into an exit point. Instead you recurse into it. But why don't you? Sure I do: The case {{{ -- We have something to float out! }}} would apply there just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 21:34:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 21:34:28 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.75ebea26fd7a018bf55c93c8757092c5@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Oh, but now you are using `type`, not a `class`/`instance` pair. Does the `type` work just fine? If that works (with quantified constraints), then I’d be happy, as user, to write {{{ type MyMonad m = (forall r. (MonadReader r m, Show r)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 21:44:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 21:44:11 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.4e63bc37a1d11689fa933a8135c9acbf@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > All join-point should have `OneOcc` Not true, it seems, as witnessed by `testsuite/tests/codeGen/should_compile/jmp_tbl.hs` (already with `-O`, so without exitification): {{{ ./inplace/bin/ghc-stage2 -dcore-lint testsuite/**/jmp_tbl.hs -O -dverbose- core2core -ddump-simpl-iterations -fforce-recomp … join { $j_s3v8 :: (# GHC.Prim.State# GHC.Prim.RealWorld, (PipeState, b_a2YY) #) [LclId[JoinId(0)]] $j_s3v8 = case lvl_s3te of wild_00 { } } in join { $j_s3ve :: (# GHC.Prim.State# GHC.Prim.RealWorld, (PipeState, b_a2YY) #) [LclId[JoinId(0)]] $j_s3ve = join { $j_s3vc :: (# GHC.Prim.State# GHC.Prim.RealWorld, (PipeState, b_a2YY) #) [LclId[JoinId(0)]] $j_s3vc = join { $j_s3va :: (# GHC.Prim.State# GHC.Prim.RealWorld, (PipeState, b_a2YY) #) [LclId[JoinId(0)]] $j_s3va = case phase_X1s7 of { __DEFAULT -> jump $j_s3v7 } } in case phase_X1s7 of { __DEFAULT -> jump $j_s3va; HCc -> jump $j_s3v8 } } in case phase_X1s7 of { __DEFAULT -> jump $j_s3vc; Ccpp -> jump $j_s3v8 } } in case phase_X1s7 of { __DEFAULT -> jump $j_s3ve; Cc -> jump $j_s3v8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 6 21:47:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Apr 2018 21:47:44 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.7ab646960ba4e2d25e82fffc621ecef5@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Those changes that I were able to do so far are now in https://phabricator.haskell.org/D4576 I will push this as soon as Harbormaster has confirmed that it does not regress anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 04:58:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 04:58:05 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.b85d3e5cffc02073584c2e9418b304ff@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, things are never easy. Yes, adding `noCSE` in the right places is the right thing to do, and it fixes this bug. But as often when fixing a “bug” in an optimization, it makes it less aggressive, and we get regressions: {{{ Nofib allocations nofib/allocs/rewrite 16255960 + 5.52% 17153208 bytes nofib/allocs/scs 902408848 + 5.22% 949533296 bytes Nofib instruction counts nofib/instr/rewrite 55292296 + 4.73% 57910048 Testsuite allocations tests/alloc/T8766 16828080 + 348.94% 75548336 bytes }}} Did not investigate anything yet (it’s 1am here). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 10:19:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 10:19:46 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.12e2f9b8cb78700f6840625722858c5f@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): Sorry for a late reply! (vacation/travelling) @simonmar: Yes, let's do a rollback - then we can fix this properly without any rush. (I'll send something today) @sgraf: Thanks a lot for analysis! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 10:36:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 10:36:06 -0000 Subject: [GHC] #14986: CmmCommonBlockElim conflicts with GhcEnableTablesNextToCode=NO In-Reply-To: <049.538cc2718b728b5d864bc8e0416ec932@haskell.org> References: <049.538cc2718b728b5d864bc8e0416ec932@haskell.org> Message-ID: <064.c5c2d2654664f120711b9aef57f8f766@haskell.org> #14986: CmmCommonBlockElim conflicts with GhcEnableTablesNextToCode=NO -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.5 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * status: new => closed * resolution: => duplicate Comment: I think this is the same as #14989 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 10:57:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 10:57:27 -0000 Subject: [GHC] #14089: Segmentation fault/access violation using Yesod and Postgresql In-Reply-To: <048.46aff377a8018fc7c501ce75cd3dd62b@haskell.org> References: <048.46aff377a8018fc7c501ce75cd3dd62b@haskell.org> Message-ID: <063.2610030f7604615e93e003ef4b6bf873@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => invalid Comment: I'm going to close this since [https://github.com/yesodweb/persistent/issues/697#issuecomment-379409667 someone else reported] that the exact same setup (i.e., a project that uses the same `Settings.StaticFiles` file) no longer segfaults with `postgresql-libpq-0.9.4.1`. Please reopen if this persists even after using that version of the library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 11:56:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 11:56:29 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 In-Reply-To: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> References: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> Message-ID: <065.4fbe81d16f7e7f93db2a0f8c9865fa58@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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:D4564 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"718a018128a0ba2ae20001c10bc8ca4d929a1d33/ghc" 718a0181/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="718a018128a0ba2ae20001c10bc8ca4d929a1d33" Fix #14238 by always pretty-printing visible tyvars Summary: Before, GHC would never print visible tyvars in the absence of `-fprint-explicit-foralls`, which led to `:kind` displaying incorrect kinds in GHCi. The fix is simple—simply check beforehand if any of the type variable binders are required when deciding when to pretty-print them. Test Plan: make test TEST=T14238 Reviewers: simonpj, goldfire, bgamari Subscribers: thomie, carter GHC Trac Issues: #14238 Differential Revision: https://phabricator.haskell.org/D4564 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 11:57:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 11:57:53 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 In-Reply-To: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> References: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> Message-ID: <065.b5007399b2f4e531a70754dd71fa55c1@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | dependent/ghci/T14238 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/ghci/T14238 * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 12:02:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 12:02:12 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.5cd80400c33b836321bdb73f26028cb4@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yeah, I think we indeed have a problem. `Rts.h` exposes symbols that are there so you can load the rts in another program and control it. These aren't needed by the runtime linker so I prefer not to have them in the symbol list. So I think you're right in that we can't really automate this. Not unless we add these symbols too, but that costs us a small amount of time at runtime for symbols that will likely never be used.. what do you think @bgamari? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 13:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 13:06:25 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.37c9ee79732d252ceb2d5e4e8f2fd7fa@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 14:06:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 14:06:36 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.a03fef966eff2aef8ca772fe3486382f@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 17:06:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 17:06:47 -0000 Subject: [GHC] #15011: Automate update of VersionHistory table Message-ID: <046.9c157386213dd1644a55281e892fb5d9@haskell.org> #15011: Automate update of VersionHistory table -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.2 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- wiki:Commentary/Libraries/VersionHistory should really be updated automatically from CI builds. This is currently generated manually with https://github.com/bgamari/ghc-utils/tree/master/library-versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 17:19:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 17:19:21 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.2e6b48553ffdecc808331ec4e239464b@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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 works fine unless your example requires partial application (`type instance F = MyMonad`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 7 17:29:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Apr 2018 17:29:09 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.60f5df44f1c292c07a999fc98abc8a73@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): I talked with alanz about this, and unfortunately, this isn't quite as straightforward to fix as with previous pretty-priner bugs. This is that we need to teach `cvtl` to put parentheses around expressions when converting `SigE`s. At the same time, we don't want to add //unnecessary// parentheses—we wouldn't want to convert `Just True :: Maybe Bool` to `(Just True) :: Maybe Bool`, for instance. Unfortunately, the machinery in GHC just isn't quite up to the task. Currently, we have the [http://git.haskell.org/ghc.git/blob/5819ae2173d4b16f1fde067d39c3c215a6adfe97:/compiler/hsSyn/HsExpr.hs#l1116 hsExprNeedsParens function], but this seems to assume that the argument `HsExpr` is occurring in a function application context. In this scenario, however, that's not the case: we have a `case` expression appearing in a type annotation context. Alas, `hsExprNeedsParens` cannot distinguish between the two contexts. I think the right path forward here is to introduce a new precedence argument to `hsExprNeedsParens`. Something like: {{{#!hs data Prec = TopPrec -- Top-level | SigPrec -- Argument of a type annotation (_ :: Foo) | OpPrec -- Argument of an infix operator (_ + 1) | AppPrec -- Argument of a prefix function (f _) }}} And use that to inform `hsExprNeedsParen` in the relevant cases. It's worth noting that this data type is tantalizingly close the existing [http://git.haskell.org/ghc.git/blob/5819ae2173d4b16f1fde067d39c3c215a6adfe97:/compiler/basicTypes/BasicTypes.hs#l700 TyPrec] data type: {{{#!hs data TyPrec = TopPrec -- No parens | FunPrec -- Function args; no parens for tycon apps | TyOpPrec -- Infix operator | TyConPrec -- Tycon args; no parens for atomic }}} Save for the fact that `TyPrec` currently doesn't have a `SigPrec` constructor, and `TyPrec` has this funny business with `FunPrec`. It might be worth considering if my proposed `Prec` and `TyPrec` could be merged. Alas, I've run out of time, so this won't be happening today. One last note: it turns out there's similar problems in the Template Haskell pretty-printer as well: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} module Bug2 where import Language.Haskell.TH main :: IO () main = putStrLn $([d| f :: Bool -> Bool f x = case x of (True :: Bool) -> True (False :: Bool) -> False g :: Bool -> Bool g x = (case x of True -> True False -> False) :: Bool |] >>= stringE . pprint) }}} {{{ f_0 :: GHC.Types.Bool -> GHC.Types.Bool f_0 x_1 = case x_1 of GHC.Types.True :: GHC.Types.Bool -> GHC.Types.True GHC.Types.False :: GHC.Types.Bool -> GHC.Types.False g_2 :: GHC.Types.Bool -> GHC.Types.Bool g_2 x_3 = case x_3 of GHC.Types.True -> GHC.Types.True GHC.Types.False -> GHC.Types.False :: GHC.Types.Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 00:42:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 00:42:43 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c Message-ID: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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: -------------------------------------+------------------------------------- Take these two files: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Generics type FakeOut a = Int data family TyFamily y z data instance TyFamily a b = TyFamily Int (FakeOut b) deriving Generic1 }}} {{{#!hs module Bar where import Foo import GHC.Generics main :: IO () main = print $ from1 $ TyFamily 1 2 }}} And compile them like so: {{{ $ ghc -c Foo.hs $ ghc -c Bar.hs ./Foo.hi Declaration for Rep1_R:TyFamilyab Axiom branches Rep1_R:TyFamilyab: Iface type variable out of scope: b Cannot continue after interface file error }}} I can reproduce this with every version of GHC from 7.8.4 onward, so this is quite an old bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 00:47:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 00:47:10 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.201b8df317e05c6d23a226a65ee67907@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: deriving 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: => deriving Comment: I suspect that `DeriveGeneric` is to blame here. Here is what `-ddump- deriv` tells us about the derived `Rep1` associated type family instance for `Generic1`: {{{#!hs Derived type family instances: type GHC.Generics.Rep1 (Foo.TyFamily a_a2ta) = GHC.Generics.D1 ('GHC.Generics.MetaData "TyFamily" "Foo" "main" 'GHC.Types.False) (GHC.Generics.C1 ('GHC.Generics.MetaCons "TyFamily" 'GHC.Generics.PrefixI 'GHC.Types.False) (GHC.Generics.S1 ('GHC.Generics.MetaSel 'GHC.Base.Nothing 'GHC.Generics.NoSourceUnpackedness 'GHC.Generics.NoSourceStrictness 'GHC.Generics.DecidedLazy) (GHC.Generics.Rec0 GHC.Types.Int) GHC.Generics.:*: GHC.Generics.S1 ('GHC.Generics.MetaSel 'GHC.Base.Nothing 'GHC.Generics.NoSourceUnpackedness 'GHC.Generics.NoSourceStrictness 'GHC.Generics.DecidedLazy) (GHC.Generics.Rec0 (Foo.FakeOut b_a2q1)))) }}} Notice that `b_a2q1` is unbound in this definition! Perhaps we should be turning this into `Any`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 01:33:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 01:33:08 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.74875162cb257651e600cb2078ade8ca@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: worksforme | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => worksforme Comment: > That works fine That’s good enough for me :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 10:12:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 10:12:07 -0000 Subject: [GHC] #15013: Building nofib using llvm and HEAD fails Message-ID: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> #15013: Building nofib using llvm and HEAD fails -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: (LLVM) | 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: -------------------------------------+------------------------------------- {{{ == make all ; in /home/Andi/ghc_head/nofib/shootout/pidigits ------------------------------------------------------------------------ HC = /home/Andi/ghc_head/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2 RUNTEST_OPTS = -ghc-timing ==nofib== pidigits: time to compile Main follows... /home/Andi/ghc_head/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2 -c Main.hs -o Main.o ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180401 for x86_64-unknown-mingw32): Each block should be reachable from only one ProcPoint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[1]: *** [../../mk/suffix.mk:23: Main.o] Error 1 Failed making all in pidigits: 1 make: *** [../mk/ghc-recurse.mk:69: all] Error 1 $ opt --version LLVM (http://llvm.org/): LLVM version 5.0.1 Optimized build. Default target: x86_64-w64-windows-gnu Host CPU: skylake }}} This is on commit 8b823f270e53627ddca1a993c05f1ab556742d96 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 13:35:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 13:35:06 -0000 Subject: [GHC] #15013: Building nofib using llvm and HEAD fails In-Reply-To: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> References: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> Message-ID: <062.836689d5e8356933cc909ca5c508c426@haskell.org> #15013: Building nofib using llvm and HEAD fails -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler (LLVM) | Version: 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 AndreasK): osa on ghc-devs suspects Phab:D4417 as the culprint. Since disabling common block elimination prevents the panic that seems likely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 14:31:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 14:31:07 -0000 Subject: [GHC] #15013: Building nofib using llvm and HEAD fails In-Reply-To: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> References: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> Message-ID: <062.672197cbf39974f3edeaa1bf1ce65d73@haskell.org> #15013: Building nofib using llvm and HEAD fails -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler (LLVM) | Version: 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 sighingnow): This ticket may be duplicate with ticket:14989. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 15:39:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 15:39:39 -0000 Subject: [GHC] #15013: Building nofib using llvm and HEAD fails In-Reply-To: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> References: <047.5dd664d541cce0aa2823ac940a7bce25@haskell.org> Message-ID: <062.098c7ffc33efbcd3b6e3e8103943932b@haskell.org> #15013: Building nofib using llvm and HEAD fails -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler (LLVM) | Version: 8.5 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14989 #14986 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * differential: => Phab:D4417 * related: => #14989 #14986 * version: => 8.5 * milestone: 8.4.2 => ⊥ * resolution: => duplicate Comment: I'm pretty sure it's a duplicate of #14989. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 15:51:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 15:51:00 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.f818d1fbb8bd487451d0d67552f659c3@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer, CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * keywords: newcomer => newcomer, CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 15:58:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 15:58:42 -0000 Subject: [GHC] #14964: performance regressions from 8.0.2 to 8.4.1 In-Reply-To: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> References: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> Message-ID: <062.b62cb3c6af6ef3ff58031b03d4b8954c@haskell.org> #14964: performance regressions from 8.0.2 to 8.4.1 -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): Sorry for the delay. Yes the programs are public, but while reproduction is easy, the whole program is big and complicated. I'd like to do a bit of work first to narrow down what is changing in there. Digging into this is next on my priority list, but it's a hobby project and I'm starting a new job so give me a few weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 20:26:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 20:26:06 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.eee9d2cd8295bec705308b078cd59b75@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by josef): I've thought about this problem for some time, but never written down my ideas before. Now seemed like a good time to speak up though :-) Below are some hopefully coherenet notes. I'd introduce a new quantifier (let's call it "V") which provides '''template polymorphism'''. This quantifier can quantify over all kinds, even levity polymorphic things. The idea is that whenever a function of template polymorphic type is called, a new copy of the function will be created, specialized with the instantiated type for its template polymorphic type variables. Example: {{{ id :: V r (a :: TYPE r). a -> a id a = a }}} When we use it like in an expression like this `id #5` or `id "foo"` the typechecker creates new bindings `id_#_Int#` and `id_*_String`. These new bindings are then used as part of elaborating the expressions: `id_#_Int# #5` and `id_*_String "foo"`. {{{ id_#_Int# :: Int# -> Int# id_#_Int# a = a id_*_String :: String -> String id_*_String a = a }}} More formally: A call to a template polymorphic function must instantiate all template polymorphic type parameters. These parameters must be instantiated with either fully ground types without any variables, or variables bound by "V", the template polymorphic quantifier. A trivial point, that I still want to point out: given two (or more) calls to the same template polymorphic function with the same type instantiation only generates one new specialization. Most likely a more sophisticated naming scheme than the one I've used here will be needed to ensure that the names of the new bindings are unique. The quantifier is only allowed to be used on the top-level and must appear before any usual quantifiers. I.e. template polymorphism is rank-1. Quantified template polymorphism, i.e. having class constraints on template polymorphic type variables is not a problem. == Recursion == It is perfectly possible to support monomorphic recursion for template polymorphism. In fact, the elaboration outlined above supports monomorphic recursion out of the box. The recursive call inside of template polymorphic function would generate the same specialization as a call from outside the function, and since we don't generate multiple specializations, the call will simply be specialized to a recursive call in the new specialized function. It is likely possible to support special cases of polymorphic recursion, but it is not clear to me that it is worth the extra work. == Modules == When exporting a template polymorphic function, it's specializations should also be exported, to avoid re-generating them. However, the importing module will have to creating its own new specializations if needed. This can lead to a situation where a module has two imports which exports the same specialization of a function they in turn imported. But there is no real problem here, because it doesn't matter which one we pick since both specializations will be the same. == Extensions == One of the interesting things about this proposal is that generalizes nicely to data types. Example: {{{ data List (V r) (a :: TYPE r) = Cons a (List r a) | Nil }}} This way we get a list data type which can be used at any kind. After type checking and elaboration we will have one list data type for each runtime representation. However, supporting specialization in different modules might require a bit of thought. == Final thoughts == The gist of this proposal is that it gives control over optimization to the library writer, similarly to the RULES pragma. Though it will not help any existing programs go faster. I'd really like to see something like this in GHC. Unfortunately, I don't have the cycles to flesh out this proposal and implement it. But I'd be happy to advice if someone wants to have a go at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 20:45:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 20:45:05 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.4c11abb31608ed2dfc2c0a783fee1e3a@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Anything that wraps {{{ghci}}} into a program that users are still expected to interact with is going to start having weird special cases to undo these changes. For my specific case of {{{ghcid}}} I can remove the {{{()}}} when {{{ghcid}}} itself sends a command in (no real problem), but I also allow the user to interact with the underlying {{{ghci}}} (via the {{{--test}}} flag), and there the surprising change in behaviour is going to be unpleasant and hard to avoid without just filtering out {{{()}}} lines, some of which might be deliberate. Any chance of getting the behaviour to omit {{{()}}} added back? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 8 23:18:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Apr 2018 23:18:12 -0000 Subject: [GHC] #15014: Exhaustivity check should suggest when COMPLETE could be helpful Message-ID: <045.0133eeba46ccbee8eefdae0d555d03fa@haskell.org> #15014: Exhaustivity check should suggest when COMPLETE could be helpful -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ MacBook-Pro-97:ghc ezyang$ cat A.hs {-# LANGUAGE PatternSynonyms #-} module A where pattern F :: a -> b -> (a, b) pattern F x y = (x, y) g :: (a, b) -> (a, b) g (F x y) = (x, y) MacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 -c A.hs -Wall -fforce- recomp A.hs:8:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g’: Patterns not matched: _ | 8 | g (F x y) = (x, y) | ^^^^^^^^^^^^^^^^^^ MacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.5.20180304 }}} Any time the exhaustiveness checker throws up its hands and says that `_` is not matched, we ought to give a hint that this may have occurred due to pattern synonyms, and that the author of the pattern synonyms can help out by specifying a COMPLETE pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 01:19:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 01:19:22 -0000 Subject: [GHC] #15008: Type synonyms with hidden, determined type variables In-Reply-To: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> References: <046.f2ba6626e807c1a9017ea7cd2a720a1e@haskell.org> Message-ID: <061.2bd21d0c3ab4d8079338ac12f602304a@haskell.org> #15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.5 Resolution: worksforme | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Replying to [comment:3 Iceland_jack]: > {{{#!hs > -- GHC transforms it into > type MyMonad m = (forall xx. (MonadReader xx m, Show xx)) > }}} The power of `QuantifiedConstraints` seems to get closer to 'magic', the more I see of them! If we didn't have a FunDep on `MonadReader`, could we simulate it with an implication constraint thusly? {{{#!hs -- user writes or GHC transforms it into type MyMonad m = (forall xx. (MonadReader xx m, MonadReader xx m => Show xx)) }}} Would we then need a superclass constraint `Show xx` on `MonadReader xx m`? Or would it be sufficient if the instances were for types in `Show`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 04:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 04:31:32 -0000 Subject: [GHC] #15015: Parsing of exp_doc loses section markers Message-ID: <045.766180669f69053dd319a98a9939559e@haskell.org> #15015: Parsing of exp_doc loses section markers -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 (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: -------------------------------------+------------------------------------- This was originally filed as a Haddock issue, but was traced back to a parsing issue with GHC itself. See here for details: https://github.com/haskell/haddock/issues/797 There's a work-around (by putting extra empty lines) but that's quite fragile and would be best to fix directly in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 08:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 08:59:56 -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.0b5039c9e40635cd27307688b9849055@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): ... Although it's unclear to me ''why'' the bang has such a dramatic effect. I presumed that the call to `hGetBuf` and `hPutBuf` were responsible for this, but going up from `do_operation`, I can't see any changes in Core resulting from the changed strictness signatures. In fact, the activations go like this: {{{ GHC.IO.Handle.Text.hPutBuf -> GHC.IO.Handle.Internals.wantWritableHandle -> GHC.IO.Handle.Internals.withHandle_' -> GHC.IO.Handle.Internals.withHandle' }}} Note from the first diff in comment:10, that while the signature for `withHandle'` differs relative to HEAD, that is not the case for `withHandle_'` (hooray for names)! `withHandle_'` is lazy in its `act`ion parameter in both versions. It should probably have `C(S)`, too, if it has in `withHandle'`, but that's a separate issue. Since there is no difference in signatures for `withHandle_'`, there is no flow in strictness information to callees, which means that the bang just fixes some kind of space leak. Which is weird, because I don't see any big data structures involved with forcing the result of the `act`ion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 09:20:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 09:20:34 -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.9332a650a6e406539dc9584385c5618a@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is already reproducible for hello world. For the following program: {{{#!hs main = mapM_ (\_ -> putStrLn "hi") [0..10000] }}} we have this `+RTS -s` output under `-O2` (first HEAD, second with bangs removed in GHC.IO): {{{ 9,491,968 bytes allocated in the heap 15,504 bytes copied during GC 44,576 bytes maximum residency (2 sample(s)) 29,152 bytes maximum slop 0 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 8 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.000s 0.000s 0.0002s 0.0002s INIT time 0.000s ( 0.000s elapsed) MUT time 0.005s ( 0.005s elapsed) GC time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.006s ( 0.006s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 1,932,804,477 bytes per MUT second Productivity 89.2% of total user, 89.5% of total elapsed }}} {{{ 10,132,096 bytes allocated in the heap 16,360 bytes copied during GC 44,576 bytes maximum residency (2 sample(s)) 29,152 bytes maximum slop 0 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 8 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.000s 0.000s 0.0002s 0.0003s INIT time 0.000s ( 0.000s elapsed) MUT time 0.007s ( 0.007s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.007s ( 0.007s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 1,516,022,826 bytes per MUT second Productivity 89.6% of total user, 89.8% of total elapsed }}} So, the working set is affected, too, which I think is a necessary condition for a space leak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 09:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 09:40:03 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking Message-ID: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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 searched + hope this isn't a dupe. When using both ApplicativeDo and RecursiveDo, referring to a do-bound variable from outside of a rec block causes a GHC internal error. Here's a minimal example: {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE RecursiveDo #-} module Lib where import Control.Monad.Fix f :: MonadFix m => m () f = do a <- return () rec let b = a return () }}} The error message I get is {{{ src/Lib.hs:12:13: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1pF :-> Type variable ‘m’ = m :: * -> *, r1mX :-> Identifier[f::forall (m :: * -> *). MonadFix m => m (), TopLevelLet [] True]] • In the expression: a In an equation for ‘b’: b = a In a stmt of a 'do' block: rec let b = a | 12 | let b = a | ^ }}} I have reproduced it in 8.2.2 and 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 10:28:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 10:28:54 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.d5359ca35cfd5acd0dfe3a29a781d735@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: niteria => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 12:07:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 12:07:06 -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.b87abc4cf8cbc6f23586cb10b991ed67@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): There's no binary difference in `dump-cmm` for the hello world example (as expected) and there is no binary difference in the object files generated for GHC.IO.Handle.Text either, after `strip`ping. The only difference in GHC.IO.Handle.Internals seems to be in `do_operation` (no wonder, that was the only place Core differed). Here's the [https://www.diffchecker.com/w0h8gImt diff]. You can see that HEAD on the right somehow can jump to cbPP directly, whereas the patched version on the left needs to allocate a closure for actually calling the `act`ion (which I presume got ripped out into the `sat_entry` at the top). I'm not proficient enough with Stg/Cmm to tell why the single bang leads to better code, while the diff in Core is boring. Maybe a suprise hides in the way `catch#` is lowered? So, what should a Note look like that explains Phab:D4574? Just 'plugging a space leak'? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 12:21:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 12:21:51 -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.dc12edb9d5682cc68f8394403d47771a@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Ah, `-ddump-prep` revealed that the non-trivial argument to `catch#` on non-HEAD was turned into a one-shot PAP `sat = act h`, which allocates. Of course! That's probably where the alleged benefit of item 3 came from. Indeed `reverse-complement` and `spheres` where the biggest beneficiaries, judging from the commit message. So, we need to be strict in `act h` because otherwise it will turn into a lazy let that allocates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 12:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 12:23:36 -0000 Subject: [GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2` Message-ID: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> #15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- It must be different somehow from `tcExtendTyVarEnv` but without reading the source code, it's hard to tell what the difference is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 12:45:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 12:45:48 -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.ac627ffbacd9bca02498dac72741f3f1@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Also note how the improvements for changeset:9915b6564403a6d17651e9969e9ea5d7d7e78e7f (from 2016, from #11222) match those of changeset:7c0fff41789669450b02dc1db7f5d7babba5dee6 (from 2015, subject of item 3). Strictness with `catch#` is now a little subtle (if also a lot more correct), because callers have to make sure that their action is forced before calling it. I wonder if we get more improvements if we make `withHandle_'` and friends strict in their `act`ion parameter... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 12:54:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 12:54:58 -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.f85f00162abe626c5faa7571eed0ebcd@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Also shouldn't `catch#` at least be head-strict in its first argument? I'm pretty sure that would get rid of the bang pattern I had to introduce, while still having correct semantics: An `IO` action which throws ''when executed'' triggers the exception handler, while a call like `catch undefined h == undefined`, something I would expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 14:09:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 14:09:50 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.345425dda9b2e6a710ec78a6a144a52f@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I, too, have pondered template polymorphism for some time, but never fleshed it out even to this level. There are a few problems with this design, however: > More formally: A call to a template polymorphic function must instantiate all template polymorphic type parameters. These parameters must be instantiated with either fully ground types without any variables, or variables bound by "V", the template polymorphic quantifier. This means that, with your `id` definition, you couldn't have {{{#!hs idList :: [a] -> [a] idList = id }}} even though you could have {{{#!hs idListInt :: [Int] -> [Int] idListInt = id }}} So it seems template polymorphism would be infectious, generally requiring callers of template-polymorphic functions also to be template-polymorphic. I don't think that's a good thing. On the flip side, I don't see concretely why we need the "no variables" restriction. > It is likely possible to support special cases of polymorphic recursion, but it is not clear to me that it is worth the extra work. Generally, these schemes fail on polymorphic recursion, and I think we should do so here, too. > This can lead to a situation where a module has two imports which exports the same specialization of a function they in turn imported. But there is no real problem here, because it doesn't matter which one we pick since both specializations will be the same. I think there ''is'' a real problem here. First off, it means that the `.o` files that GHC produces won't be able to be linked by, e.g., `ld`: multiple `.o` files might have the same definitions. In the end, I think we'd have to implement some deduplication algorithm during linking, or end up with horrid code bloat. > One of the interesting things about this proposal is that generalizes nicely to data types. Under your "no variables" rule, this `List` type would have to be specialized at every possible data parameter. I'm worried about bloat. > However, supporting [data] specialization in different modules might require a bit of thought. This is also a thorny question. Here, we absolutely have to get deduplication correct, as it's a matter of correctness, not just efficiency (in size of the executable). One unaddressed question here is: what restrictions would there be on template-polymorphic levity-polymorphic variables? Presumably, none, but I'm not sure. Also, how is this different from the "compulsory unfoldings" idea earlier in this thread (started in comment:3)? The user declares template polymorphism directly (the compulsory unfoldings idea didn't have any user direction -- but perhaps it should have), and the specializations here happen by creating new bindings instead of inlining, but I'm not sure a user would really see the difference here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 14:42:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 14:42:17 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.71a85694014450a7d8a01839a59fe878@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow Comment: I think the "not is scope" is by design. See more discussion under ticket:4148. When we use `rec` in `do` blocks, rather than `mdo` blocks, the outer variables won't be included into the scope of `rec` block. The real problem is when there's no binding for `a` inside `rec` block, the rhs `a` in `let b = a` will have the same name with the outer `a`. For code: {{{#!hs }}} The rename produces: {{{#!hs Lib.f :: MonadFix m_auv => m_auv () Lib.f = do a_auw <- return () | () <- do rec let b_aux = a_auw return () return () }}} But for code: {{{#!hs f :: MonadFix m => m () f = do a <- return () rec let b = a a = () return () }}} The rename produces: {{{#!hs Lib.f :: MonadFix m_auv => m_auv () Lib.f = do a_auw <- return () | () <- do rec let b_aux = a_auy a_auy = () return () return () }}} Indeed it's a bug. I'm optimistic to assign that to myself :) We also should note this behavior of `rec` in documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 14:52:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 14:52:07 -0000 Subject: [GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2` In-Reply-To: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> References: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> Message-ID: <064.ab88dc0df332dac7ef90cd537fca0b1a@haskell.org> #15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Also `scopeTyVars2`. What about to rename `scopeTyVars2` to `scopeTyVarsWithName` and `tcExtendTyVarEnv2` to `tcExtendTyVarEnvWithName` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 14:54:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 14:54:35 -0000 Subject: [GHC] #4020: Please consider adding support for local type synonyms In-Reply-To: <041.4d1fc687182926effba30be48457cbb9@haskell.org> References: <041.4d1fc687182926effba30be48457cbb9@haskell.org> Message-ID: <056.085de0228351b9973af450fc1192ef39@haskell.org> #4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym 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 Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 15:24:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 15:24:03 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.25f3b5680eeafb3674832fb9d7d9fc59@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode, | 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 Azel): From what I can see on various C and C++ documentations (i.e. [https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/isalnum- iswalnum-isalnum-l-iswalnum-l Microsoft's], [https://www.gnu.org/software/libc/manual/html_node/Classification-of- Wide-Characters.html#Classification-of-Wide-Characters the glibc's] or [http://en.cppreference.com/w/cpp/string/wide/iswalnum cppreference.com's] which refers us [http://www.open-std.org/JTC1/SC35/WG5/docs/30112d10.pdf here]) `iswalnum`'s behaviour should be to return `True` if either of `iswalpha` or `iswdigit` does, so I guess `isAlphaNum` ought to do the same. That is, keeping the documentation as it is and fixing `u_iswalnum`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 16:01:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 16:01:34 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.52993ec58645c8e00fbb273f9424b74f@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, maybe. The original program and the program in comment:11 have another key difference. The latter uses `UndecidableInstances`, so I suppose it's entirely reasonable that we get a stack overflow error on that one. The former program, on the other hand, does not use `UndecidableInstances`. Really, we ought to reject the former program outright with an error message similar to the one that we get if we leave off `UndecidableInstances` from the latter program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a instance C b a => C b (Foo a) where c (Foo a) = c a }}} {{{ Bug.hs:12:10: error: • Illegal instance declaration for ‘C b (Foo a)’ The coverage condition fails in class ‘C’ for functional dependency: ‘a -> b’ Reason: lhs type ‘b’ does not determine rhs type ‘Foo a’ Un-determined variable: a Using UndecidableInstances might help • In the instance declaration for ‘C b (Foo a)’ | 12 | instance C b a => C b (Foo a) where | ^^^^^^^^^^^^^^^^^^^^ }}} If we did this, then I would consider this issue resolved. This coverage condition check is performed in `checkValidInstance`. Curiously, we don't call `checkValidInstance` on derived instances at the comment. There are relevant comments [http://git.haskell.org/ghc.git/blob/b14c03737574895718eed786a60dfdfd42ab49ce:/compiler/typecheck/TcDerivInfer.hs#l594 here]: {{{#!hs -- checkValidInstance tyvars theta clas inst_tys -- Not necessary; see Note [Exotic derived instance contexts] ; traceTc "TcDeriv" (ppr deriv_rhs $$ ppr theta) -- Claim: the result instance declaration is guaranteed valid -- Hence no need to call: -- checkValidInstance tyvars theta clas inst_tys }}} As this ticket shows, this isn't quite right. So perhaps we need to carve out the bit that checks the coverage condition and just check that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 17:10:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 17:10:01 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD Message-ID: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | 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, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` * `directory` * `filepath` * `ghc-boot-th` * `ghc-compat` * `ghci` * `haddock` * `haskeline` * `hpc` * `parallel` * `parsec` * `primitive` * `process` * `stm` * `template-haskell` * `terminfo` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 17:13:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 17:13:13 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.df52b2861b1f19bf42a9ef87707962b9@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` > * `directory` > * `filepath` > * `ghc-boot-th` > * `ghc-compat` > * `ghci` > * `haddock` > * `haskeline` > * `hpc` > * `parallel` > * `parsec` > * `primitive` > * `process` > * `stm` > * `template-haskell` > * `terminfo` > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` * `directory` * `filepath` * `ghc-boot-th` (in-place) * `ghc-compat` (in-place) * `ghci` (in-place) * `haddock` * `haskeline` * `hpc` * `parallel` * `parsec` * `primitive` * `process` * `stm` * `template-haskell` (in-place) * `terminfo` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 18:29:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 18:29:13 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.c416a136acd6e819c49b106d9384bc04@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 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 bgamari): > I couldn't find a relevant note, so I resorted to experimentation. It appears that the unwind annotation reflects the state after A, but before B. That is correct. Indeed it looks like my patch is wrong. I don't know what I was thinking when I wrote it. Good catch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 19:17:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 19:17:46 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.5b34be1bbc2fc7486ef5289d6698340e@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by tdammers): This patch actually causes a few performance regression tests to fail. I bumped the expected values for now, but they need looking into at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 19:37:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 19:37:30 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 Message-ID: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #14737 Differential Rev(s): D4568 | Wiki Page: -------------------------------------+------------------------------------- #14737, while drastically improving performance on some edge cases, introduces performance regressions in 3 test cases: perf/compiler/parsing001.run perf/compiler/T9020.run perf/compiler/T12707.run -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 21:30:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 21:30:33 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.cb52078ef408fa2430fde37a08de429a@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Using `noCSE` was the wrong way of fixing this. I have fixed this bug now more properly, less invasively, and with a Note (still at Phab:D4572). The solution is to simply use `collectNBinders` when traversing into a join point. I am fairly confident, so will push if Harbormaster is happy with it, but review is of course still appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 9 23:16:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Apr 2018 23:16:03 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.eccfc8cdfed80e91a7dd620aa711ffcb@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually GHC already does this, or something very like it. See `Note [When does an implication have given equalities?]` and especially `Note [Let-bound skolems]` in `TcSMonad`. I don't say that it's perfectly implemented (eg I'm a bit worried about whether it's sensitive to whether the constraint looks like `a ~ b` or `b ~ a`) but it does more or less what you way. Your condition (%) doesn't look right. After all, in your example the constraint `a ~ b` has both `a` and `b` free -- and the former is not locally bound. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 02:15:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 02:15:14 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.ef9e5750eacbc80dd6ddf6b97f6acd77@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: patch Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"ae0cff0a1834d8b041b06d0e1ab6ce969aac44c8/ghc" ae0cff0a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae0cff0a1834d8b041b06d0e1ab6ce969aac44c8" CSE: Walk past join point lambdas (#15002) As the CSE transformation traverses the syntax tree, it needs to go past the lambdas of a join point, and only look for CSE opportunities inside, as a join point’s lambdas must be preserved. Simple fix; comes with a Note and a test case. Thanks to Ryan Scott for an excellently minimized test case, and for bisecting GHC. Differential Revision: https://phabricator.haskell.org/D4572 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 02:16:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 02:16:17 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.d6b756225c960d37c3d2a791095711f4@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: merge Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: Fixed in ae0cff0a1834d8b041b06d0e1ab6ce969aac44c8. I guess this is the kind of stuff we want in the stable release as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 03:23:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 03:23:00 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.5816648f3fd1ea091684ea917cc959bb@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): Replying to [comment:23 RyanGlScott]: > songzh, I finally delivered on my promise to implement the ability to use `PartialTypeSignatures` in standalone `deriving` declarations //à la// `deriving _ => Eq (Foo a)`. Does this make things easier for you on your end? Yes! Your `Any` wrinkle has worked very well already, but this will make a lot improvement for `derive-topdown` package. With new `PartialTypeSignatures` a lot of code can be removed in the package, but for compatibility reason, I will keep them for older GHC. Even though class instance contexts can be generated and inferred now and type role is carefully handled for now, three other packages,`primitive`, `th-expand-syns`, `transformers` ,still are needed. This stops current `derive-topdown` being used inside ghc's code, so I will write a minimal package in order to reduce the dependencies of `derive-topdown`. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 08:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 08:30:49 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.b2a0ab9a26fc1af87f53c20192996e7c@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Great! Do you consider this issue to be resolved, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 08:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 08:36:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.12dbeb4b935de1c2ac5c3f0201889142@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.4.3 => 8.4.2 Comment: I'm a bit confused as to what the current status of this ticket is. comment:5 identifies a commit (not yet merged into GHC 8.4.2) which apparently fixes this issue, but simonpj suggests in comment:6 that there is more to be done. Either way, we should backport //some// sort of fix to 8.4.2. Thoughts, noneata? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 09:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 09:51:09 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.83ccfa8ad088135b4e9ccba2c5a604bd@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 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: | 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 Apr 10 10:50:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 10:50:37 -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.8157921400d725c06f7bde2adf3ad427@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): As expressed in Phab:D4574#126789 I have doubts that we should really merge the diff for item 2. According to `#exceptions_and_strictness#` in GHC.IO `catchException` and `catchAny` have that bang on purpose, as a helper function when `catch#` moved to a lazy signature in #11555. ticket:11222#comment:6 is very relevant. Such a `raiseIO#` is exactly what `catchException` and `catchAny` would need. Somewhere above, I discovered that `GHC.IO.Handle.Internals.want*Handle` aren't strict in their `act`ions. I'm currently evaluating any performance benefits by adding bangs in appropriate positions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 10:53:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 10:53:31 -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.8386a63c99676d19d0c365311d7b4a32@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 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): * cc: dfeuer (added) Comment: CCing @dfeuer, as he seems to have ample experience with `catch#`. No need to react right now, just let me know if you see me going anywhere you already were. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:21:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:21:11 -0000 Subject: [GHC] #4942: GHC.ConsoleHandler does not call back application when Close button is pressed In-Reply-To: <045.ed5c0707de124f67b6d45637526a6c9d@haskell.org> References: <045.ed5c0707de124f67b6d45637526a6c9d@haskell.org> Message-ID: <060.755fa0675fcd30984ea4687ded4f5749@haskell.org> #4942: GHC.ConsoleHandler does not call back application when Close button is pressed -------------------------------------+------------------------------------- Reporter: Amatic | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pdedecker): I have an console application that communicates with external hardware (scientific instruments). This hardware needs to be initialized at application start and cleanly shut down at application end, otherwise damage or increased wear can result. Unfortunately, many users close the program by hitting the "X" close button on the console window, even when trained not to. Years of routine are hard to beat. This bug prevents me from solving this, by making it impossible to run safely shut down the equipment in response to a close event. Please make it possible to handle these events and run cleanup code. Regarding the possibility of the Haskell code leading to an unkillable window: google suggests that the application will be terminated after a timeout, even if the handler function hasn't returned yet. So this may not be an issue in practice? (e.g. https://stackoverflow.com/questions/47041407/why-does-my-windows-console- close-event-handler-time-out) ALSO: the documentation for GHC.ConsoleHandler should reflect that Close events are ignored, which does not appear to be the case at present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:27:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:27:39 -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.1ecf852756562bd54f4b72abccb4c344@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Re: item 4. Isn't [https://hackage.haskell.org/package/ghc-8.4.1/docs/CoreUtils.html#v:exprOkForSpeculation exprOkForSpeculation or exprOkForSideEffects] exactly what we want, rather than just `isPrimOpId`? I don't think the limited convergence checking that nested CPR would bring (it should not allow arbitrary costly converging expression anyway) has any benefit over those functions. I could give those a try, if you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:33:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:33:41 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.73b6bc996c8f0567aee4dde3a9b30263@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` > * `directory` > * `filepath` > * `ghc-boot-th` (in-place) > * `ghc-compat` (in-place) > * `ghci` (in-place) > * `haddock` > * `haskeline` > * `hpc` > * `parallel` > * `parsec` > * `primitive` > * `process` > * `stm` > * `template-haskell` (in-place) > * `terminfo` > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` * `directory` * `filepath` * `ghc-boot-th` (in-place) * `ghc-compat` (in-place) * `ghci` (in-place) * `haddock` * `haskeline` * `hpc` * `parsec` * `process` * `stm` * `template-haskell` (in-place) * `terminfo` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:39:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:39:37 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.a1d61371b3ed27f662605553be662037@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` > * `directory` > * `filepath` > * `ghc-boot-th` (in-place) > * `ghc-compat` (in-place) > * `ghci` (in-place) > * `haddock` > * `haskeline` > * `hpc` > * `parsec` > * `process` > * `stm` > * `template-haskell` (in-place) > * `terminfo` > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) * `directory` (https://github.com/haskell/directory/pull/79) * `filepath` (done, https://github.com/haskell/filepath/pull/67) * `ghc-boot-th` (in-place) * `ghc-compat` (in-place) * `ghci` (in-place) * `haddock` * `haskeline` * `hpc` * `parsec` (https://github.com/haskell/parsec/pull/90) * `process` * `stm` * `template-haskell` (in-place) * `terminfo` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:40:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:40:36 -0000 Subject: [GHC] #15020: PatternSynonyms: Problems with quantified constraints / foralls Message-ID: <051.dc34120fba728e1a69cd66ce48b598e6@haskell.org> #15020: PatternSynonyms: Problems with quantified constraints / foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I couldn't find a way to implement `PLam2` as a simply bidirectional pattern synonym, I expected it to work but I recall a similar ticket. I couldn't find it though. {{{#!hs {-# Language RankNTypes, PatternSynonyms, ViewPatterns #-} newtype Lam1 = Lam1 (forall xx mm. Monad mm => mm xx) pattern PLam1 :: (forall xx mm. Monad mm => mm xx) -> Lam1 pattern PLam1 a = Lam1 a -- newtype Lam2 a = Lam2 (forall mm. Monad mm => mm a) newtype Forall f = Forall (forall xx. f xx) -- · FAILS · -- pattern PLam2 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 -- pattern PLam2 lam = Forall (Lam2 lam) -- get :: Forall Lam2 -> forall xx mm. Monad mm => mm xx get (Forall (Lam2 lam)) = lam pattern PLam3 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 pattern PLam3 lam <- (get -> lam) where PLam3 lam = Forall (Lam2 lam) }}} The complaint is and I wonder if this is a limitation of PatternSynonyms {{{ • Couldn't match type ‘xx0’ with ‘xx’ because type variable ‘xx’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall xx (mm :: * -> *). Monad mm => mm xx at Test.hs:16:34-36 Expected type: mm xx Actual type: mm xx0 • In the declaration for pattern synonym ‘PLam2’ • Relevant bindings include lam :: forall (mm :: * -> *). Monad mm => mm xx0 (bound at Test.hs:16:34) | 16 | pattern PLam2 lam = Forall (Lam2 lam) | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:40:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:40:59 -0000 Subject: [GHC] #15020: PatternSynonyms: Problems with quantified constraints / foralls In-Reply-To: <051.dc34120fba728e1a69cd66ce48b598e6@haskell.org> References: <051.dc34120fba728e1a69cd66ce48b598e6@haskell.org> Message-ID: <066.1543f34ae9c73fda591af11dc550dbb7@haskell.org> #15020: PatternSynonyms: Problems with quantified constraints / foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I couldn't find a way to implement `PLam2` as a simply bidirectional > pattern synonym, I expected it to work but I recall a similar ticket. I > couldn't find it though. > > {{{#!hs > {-# Language RankNTypes, PatternSynonyms, ViewPatterns #-} > > newtype Lam1 = Lam1 (forall xx mm. Monad mm => mm xx) > > pattern PLam1 :: (forall xx mm. Monad mm => mm xx) -> Lam1 > pattern PLam1 a = Lam1 a > > -- > > newtype Lam2 a = Lam2 (forall mm. Monad mm => mm a) > > newtype Forall f = Forall (forall xx. f xx) > > -- · FAILS · > -- pattern PLam2 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 > -- pattern PLam2 lam = Forall (Lam2 lam) > > -- > > get :: Forall Lam2 -> forall xx mm. Monad mm => mm xx > get (Forall (Lam2 lam)) = lam > > pattern PLam3 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 > pattern PLam3 lam <- (get -> lam) > where PLam3 lam = Forall (Lam2 lam) > }}} > > The complaint is and I wonder if this is a limitation of PatternSynonyms > > {{{ > • Couldn't match type ‘xx0’ with ‘xx’ > because type variable ‘xx’ would escape its scope > This (rigid, skolem) type variable is bound by > a type expected by the context: > forall xx (mm :: * -> *). Monad mm => mm xx > at Test.hs:16:34-36 > Expected type: mm xx > Actual type: mm xx0 > • In the declaration for pattern synonym ‘PLam2’ > • Relevant bindings include > lam :: forall (mm :: * -> *). Monad mm => mm xx0 > (bound at Test.hs:16:34) > | > 16 | pattern PLam2 lam = Forall (Lam2 lam) > | ^^^ > }}} New description: I couldn't find a way to implement `PLam2` as a simply bidirectional pattern synonym, I expected it to work but I recall a similar ticket. I couldn't find it though. {{{#!hs {-# Language RankNTypes, PatternSynonyms, ViewPatterns #-} newtype Lam1 = Lam1 (forall xx mm. Monad mm => mm xx) pattern PLam1 :: (forall xx mm. Monad mm => mm xx) -> Lam1 pattern PLam1 a = Lam1 a -- newtype Lam2 a = Lam2 (forall mm. Monad mm => mm a) newtype Forall f = Forall (forall xx. f xx) -- · FAILS · -- pattern PLam2 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 -- pattern PLam2 lam = Forall (Lam2 lam) -- get :: Forall Lam2 -> forall xx mm. Monad mm => mm xx get (Forall (Lam2 lam)) = lam pattern PLam3 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 pattern PLam3 lam <- (get -> lam) where PLam3 lam = Forall (Lam2 lam) }}} The complaint is `V`, I wonder if this is a limitation of PatternSynonyms {{{ • Couldn't match type ‘xx0’ with ‘xx’ because type variable ‘xx’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall xx (mm :: * -> *). Monad mm => mm xx at Test.hs:16:34-36 Expected type: mm xx Actual type: mm xx0 • In the declaration for pattern synonym ‘PLam2’ • Relevant bindings include lam :: forall (mm :: * -> *). Monad mm => mm xx0 (bound at Test.hs:16:34) | 16 | pattern PLam2 lam = Forall (Lam2 lam) | ^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 11:47:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 11:47:33 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.5f17b2f77b0f480fadb296350579d733@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) > * `directory` (https://github.com/haskell/directory/pull/79) > * `filepath` (done, https://github.com/haskell/filepath/pull/67) > * `ghc-boot-th` (in-place) > * `ghc-compat` (in-place) > * `ghci` (in-place) > * `haddock` > * `haskeline` > * `hpc` > * `parsec` (https://github.com/haskell/parsec/pull/90) > * `process` > * `stm` > * `template-haskell` (in-place) > * `terminfo` > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) * `directory` (https://github.com/haskell/directory/pull/79) * `filepath` (done, https://github.com/haskell/filepath/pull/67) * `ghc-boot-th` (in-place) * `ghc-compat` (in-place) * `ghci` (in-place) * `haddock` * `haskeline` (https://github.com/judah/haskeline/pull/81) * `hpc` * `parsec` (https://github.com/haskell/parsec/pull/90) * `process` (https://github.com/haskell/process/pull/124) * `stm` (https://github.com/haskell/stm/pull/7) * `template-haskell` (in-place) * `terminfo` (https://github.com/judah/terminfo/pull/30) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 12:01:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 12:01:20 -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.f87cc05863b6d21fa948e52dbb099b65@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Re: Making `want*Handle` strict in their `act`ions in comment:19. This regresses all over the place and I don't really know why. Maybe because `case f x of g -> case g y of res -> res` is operationally different than `case f x y of res -> res`? Maybe it's because one-shot information worsened? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 12:08:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 12:08:27 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.c22b10ef186f32e65a08c2b03ae7d4a4@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) > * `directory` (https://github.com/haskell/directory/pull/79) > * `filepath` (done, https://github.com/haskell/filepath/pull/67) > * `ghc-boot-th` (in-place) > * `ghc-compat` (in-place) > * `ghci` (in-place) > * `haddock` > * `haskeline` (https://github.com/judah/haskeline/pull/81) > * `hpc` > * `parsec` (https://github.com/haskell/parsec/pull/90) > * `process` (https://github.com/haskell/process/pull/124) > * `stm` (https://github.com/haskell/stm/pull/7) > * `template-haskell` (in-place) > * `terminfo` (https://github.com/judah/terminfo/pull/30) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) * `directory` (https://github.com/haskell/directory/pull/79) * `filepath` (done, https://github.com/haskell/filepath/pull/67) * `ghc-boot-th` (in-place) * `ghc-compat` (in-place) * `ghci` (in-place) * `haddock` (https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (https://github.com/judah/haskeline/pull/81) * `hpc` * `parsec` (https://github.com/haskell/parsec/pull/90) * `process` (done, https://github.com/haskell/process/pull/124) * `stm` (https://github.com/haskell/stm/pull/7) * `template-haskell` (in-place) * `terminfo` (https://github.com/judah/terminfo/pull/30) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 12:10:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 12:10:58 -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.e9988b1711302b343801e6143bf43c31@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah, I knew ''something'' around here got reverted on performance grounds. Sorry I mixed up which bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 12:32:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 12:32:56 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.fa1590ba0d97aef01319b4eccf56d3f1@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` > * `deepseq` (done, https://github.com/haskell/deepseq/pull/41) > * `directory` (https://github.com/haskell/directory/pull/79) > * `filepath` (done, https://github.com/haskell/filepath/pull/67) > * `ghc-boot-th` (in-place) > * `ghc-compat` (in-place) > * `ghci` (in-place) > * `haddock` > (https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) > * `haskeline` (https://github.com/judah/haskeline/pull/81) > * `hpc` > * `parsec` (https://github.com/haskell/parsec/pull/90) > * `process` (done, https://github.com/haskell/process/pull/124) > * `stm` (https://github.com/haskell/stm/pull/7) > * `template-haskell` (in-place) > * `terminfo` (https://github.com/judah/terminfo/pull/30) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` (ready, http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) * `directory` (awaiting, https://github.com/haskell/directory/pull/79) * `filepath` (ready, https://github.com/haskell/filepath/pull/67) * `ghc-boot-th` (ready, in-place) * `ghc-compat` (ready, in-place) * `ghci` (ready, in-place) * `haddock` (ready, https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/81) * `hpc` (ready, http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) * `parsec` (awaiting, https://github.com/haskell/parsec/pull/90) * `process` (ready, https://github.com/haskell/process/pull/124) * `stm` (awaiting, https://github.com/haskell/stm/pull/7) * `template-haskell` (ready, in-place) * `terminfo` (awaiting, https://github.com/judah/terminfo/pull/30) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 12:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 12:54:45 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.9a192dc845840ffcb2fb67d6bae175c8@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): On Windows Server 2016 (as provisioned by AWS Windows instances, into which I RDP'd), with the Locale set to Japanese (as described in https://www.java.com/en/download/help/locale.xml -- this sets the code page, as shown by `chcp`, to `932` in PowerShell and cmd.exe), when trying to reproduce the bug with the code from the issue description, **I already see GHC itself dying with the same error** during `stack setup`: {{{ PS C:\Users\日\Desktop\ghc-bug-8118> stack setup The GHC located at C:\Users\譌･ \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc.EXE failed to compile a sanity check. Please see: http://docs.haskellstack.org/en/stable/install_and_upgrade/ for more information. Exception was: Running C:\Users\譌･ \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc.EXE C:\Users\譌･\AppData\Local\Temp\4\stack-sanity-check32792\Main.hs -no- user-package-db in directory C:\Users\譌･\AppData\Local\Temp\4\stac k-sanity-check32792\ exited with ExitFailure 1 [1 of 1] Compiling Main ( C:\Users\・ｽ・ｽ\AppData\Local\Temp\4 \stack-sanity-check32792\Main.hs, C:\Users\・ｽ・ｽ\AppData\Local\Temp\4 \stack-sanity-check32792\Main.o ) Linking C:\Users\・ｽ・ｽ\AppData\Local\Temp\4\stack-sanity- check32792\Main.exe ... C:\Users\・ｽ・ｽ\AppData\Local\Temp\4\ghc34616_0\ghc_6.rsp: commitBuffer: invalid argument (invalid character) }}} (Note that this is not how I see it in PowerShell, where all backslashes are replaced by the Yen sign, but this is as I see it when I copy-paste the output into Sublime Text 3 or a Firefox window). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 13:24:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 13:24:38 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.99e6d45826f74e329dca300959d32d80@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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 nomeata): Thanks for bringing this to my attention. The mentioned commit probably only hides the issue, but does not fix it, and it needs to be fixed as Simon describes. `T15005.hs` produces the test case on `ghc-8.4`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 13:27:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 13:27:53 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.677846f95a9d5f71e4cff49d4fab15a8@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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 Joachim Breitner ): In [changeset:"3f59d3802170f495702674b4f8e4e80247803654/ghc" 3f59d380/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3f59d3802170f495702674b4f8e4e80247803654" Add test case for #15005 this succeeds on `master` right now, but I confirmed that it fails on ghc-8.4.1-release. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 13:46:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 13:46:39 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.526572209433589a40f70b7afd9890f1@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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): Phab:D4582 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D4582 Comment: Simons diagnosis is correct: I implemented it, and it fixes the bug, even on the 8.4 branch. If Harbormaster is happy with my patch at Phab:D4582 I will push it to master and request this to be merged into 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 14:21:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 14:21:40 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path Message-ID: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path ----------------------------------------+--------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10762 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Below I will attach examples of how `ghc-pkg list` crashes with {{{ : commitBuffer: invalid argument (invalid character) }}} when the user name contains a non-ASCII character (in my case `日`). I don't think it's important what the user name is, but more likely whether or not `日` is in some path (probably the path to the package database). The issue is trivially reproducible (I tried on Windows 10, and Server 2016 as deployed by AWS) with cmd.exe and PowerShell. In the below, `chcp 20127` sets the code page to US-ASCII, and `chcp 65001`, sets it to UTF-8. This per-terminal / per-process setting is different from the system locale (as can be set [https://www.java.com/en/download/help/locale.xml this way]). The the behaviour of different combinations of system locale and code page: * English (US) system locale * `chcp 437` (English default): **crash** * `chcp 65001` (UTF-8): no crash * `chcp 20127` (ASCII): **crash** * Japanese system locale * `chcp 932` (Japanese default): no crash * `chcp 65001` (UTF-8): no crash * `chcp 20127` (ASCII): **crash** In none of these situatins should `ghc-pkg list` crash. It breaks all the build tools; from conversatins on the `haskell-jp` Slack, I have learned that Japanese users have learned to avoid unicode in their user names due to this issue. I believe the fix to `ghc-pkg` should be similar to [https://github.com/ghc/ghc/commit/1b56c40578374a15b4a2593895710c68b0e2a717 this fix for `ghc`] (#10762), where the encoding of the stdout `Handle` is set to UTF-8. ---- With English (US) system locale, as copy-pasted from PowerShell: {{{ Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS C:\Users\日> chcp Active code page: 437 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\ghc-pkg.EXE: : commitBuffer: invalid argument (invalid character) PS C:\Users\日> chcp 65001 Active code page: 65001 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 20127 Active code page: 20127 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\ghc-pkg.EXE: : commitBuffer: invalid argument (invalid character) }}} With Japanese system locale, as copied from PowerShell: {{{ Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS C:\Users\日> chcp Active code page: 932 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 65001 Active code page: 65001 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 20127 Active code page: 20127 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\ghc-pkg.exe: : commitBuffer: invalid argument (invalid character) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 14:22:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 14:22:25 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.5a374b7625992a9ab27d5e3a6e6a0f96@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ----------------------------------+-------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037, #15021 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by nh2): * related: #6037 => #6037, #15021 Comment: Related ticket for `ghc-pkg list` that also breaks build tools: #15021 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:36:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:36:09 -0000 Subject: [GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values In-Reply-To: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> References: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> Message-ID: <059.88af722103f075fcd2a47a0d358d28f9@haskell.org> #10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/Numeric/sqrt Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5161609117c16cb7b29b2b8b1cd41e74341d4137/ghc" 5161609/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5161609117c16cb7b29b2b8b1cd41e74341d4137" testsuite: Add test for negative sqrts (#10010) Reviewers: hvr, alpmestan Reviewed By: alpmestan Subscribers: thomie, carter GHC Trac Issues: #10010 Differential Revision: https://phabricator.haskell.org/D4543 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:36:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:36:24 -0000 Subject: [GHC] #14947: internal error: Invalid object *c in push() In-Reply-To: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> References: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> Message-ID: <060.b854247cfc01306cf861fcce5a317455@haskell.org> #14947: internal error: Invalid object *c in push() -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 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 Ben Gamari ): In [changeset:"d5f6d7a03d66a93ec05a90948126feffc9279dc6/ghc" d5f6d7a0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5f6d7a03d66a93ec05a90948126feffc9279dc6" rts/RetainerProfile: Handle BLOCKING_QUEUES push() considers BLOCKING_QUEUES to be an invalid closure type which should never be present on the stack. However, retainClosure made no accomodation for this and ended up pushing such a closure. This lead to #14947. Test Plan: Validate Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: thomie, carter, RyanGlScott GHC Trac Issues: #14947 Differential Revision: https://phabricator.haskell.org/D4538 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:36:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:36:52 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.a1788aa3b5f2a2de8abeee296a1f0c51@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4553 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2534164aefd346c7c51b70e8e8c49aa881dd9f85/ghc" 2534164/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2534164aefd346c7c51b70e8e8c49aa881dd9f85" Move gmp/config.mk.in to config.mk.in, fix #14972 Here's how the rube goldberg machine triggered the old bug: 1. If you have a file gmp/config.mk.in, then Cabal will create a generated file in $DIST/build/gmp/config.mk 2. When you attempt to load inplace integer-gmp via GHCi, it will ask gcc (aka clang on OS X) for the file name of 'gmp', with base directory set to $DIST/build 3. There is a folder named 'gmp', and so this folder is returned as the 'library' for gmp 4. GHCi loadArchive chokes to death trying to open a library that is actually a folder This patch solves the problem by breaking the chain at (1): if we don't put config.mk in a folder named gmp, NO PROBLEM. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: angerman, hvr, bgamari Reviewed By: angerman Subscribers: erikd, thomie, carter GHC Trac Issues: #14972 Differential Revision: https://phabricator.haskell.org/D4552 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:37:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:37:07 -0000 Subject: [GHC] #14987: Memory usage exploding for complex pattern matching In-Reply-To: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> References: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> Message-ID: <062.beb8651ed0a64e7c89a51235d742de95@haskell.org> #14987: Memory usage exploding for complex pattern matching -------------------------------------+------------------------------------- Reporter: vmiraldo | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c054162ae151ff82d43e504836784a7bc7827d9f/ghc" c054162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c054162ae151ff82d43e504836784a7bc7827d9f" Revert "Fix #14838 by marking TH-spliced code as FromSource" This reverts commit ffb2738f86c4e4c3f0eaacf0a95d7326fdd2e383. Due to #14987. Reviewers: goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie, carter GHC Trac Issues: #14987, #14838 Differential Revision: https://phabricator.haskell.org/D4545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:37:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:37:07 -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.c37a89df392f9a79e722047f5392afee@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | 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: | Differential Rev(s): Phab:D4440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c054162ae151ff82d43e504836784a7bc7827d9f/ghc" c054162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c054162ae151ff82d43e504836784a7bc7827d9f" Revert "Fix #14838 by marking TH-spliced code as FromSource" This reverts commit ffb2738f86c4e4c3f0eaacf0a95d7326fdd2e383. Due to #14987. Reviewers: goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie, carter GHC Trac Issues: #14987, #14838 Differential Revision: https://phabricator.haskell.org/D4545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:37:22 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.c09c747cde890fb73ed88c48c431c2d8@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14683 #14975 | Differential Rev(s): D4394 D4395 #14737 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7bb7f991e2b04b7daed079bab9e63884404802a0/ghc" 7bb7f99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7bb7f991e2b04b7daed079bab9e63884404802a0" Discard reflexive casts during Simplify Trac #14735 (derived from Trac #11735) found that 75% of compile time was being spent in simplCast. This patch is the first in a series to deal with that problem. This particular patch actually has very little effect on performance; it just refactors simplCast so that it builds Refl coercions less often. Refl coercions require us to compute the type to put inside them, and even if that's done lazily it is still work and code. Instead we use Maybe Coercion with Nothing for Refl. This change also percolates to pushCoTyArg and pushValArg. Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14737 Differential Revision: https://phabricator.haskell.org/D4395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:37:22 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.00cb084d90ecb800f38bbbc0a2a417a1@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7bb7f991e2b04b7daed079bab9e63884404802a0/ghc" 7bb7f99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7bb7f991e2b04b7daed079bab9e63884404802a0" Discard reflexive casts during Simplify Trac #14735 (derived from Trac #11735) found that 75% of compile time was being spent in simplCast. This patch is the first in a series to deal with that problem. This particular patch actually has very little effect on performance; it just refactors simplCast so that it builds Refl coercions less often. Refl coercions require us to compute the type to put inside them, and even if that's done lazily it is still work and code. Instead we use Maybe Coercion with Nothing for Refl. This change also percolates to pushCoTyArg and pushValArg. Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14737 Differential Revision: https://phabricator.haskell.org/D4395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 15:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 15:37:22 -0000 Subject: [GHC] #14735: GHC Panic with QuantifiedConstraints In-Reply-To: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> References: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> Message-ID: <066.01865188c0b37839d20d1364af4bd2a1@haskell.org> #14735: GHC Panic with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: wipT2893, | 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7bb7f991e2b04b7daed079bab9e63884404802a0/ghc" 7bb7f99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7bb7f991e2b04b7daed079bab9e63884404802a0" Discard reflexive casts during Simplify Trac #14735 (derived from Trac #11735) found that 75% of compile time was being spent in simplCast. This patch is the first in a series to deal with that problem. This particular patch actually has very little effect on performance; it just refactors simplCast so that it builds Refl coercions less often. Refl coercions require us to compute the type to put inside them, and even if that's done lazily it is still work and code. Instead we use Maybe Coercion with Nothing for Refl. This change also percolates to pushCoTyArg and pushValArg. Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14737 Differential Revision: https://phabricator.haskell.org/D4395 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 16:21:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 16:21:51 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.59c86e48fb54ea7371664bce0ede3426@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I dug through `dump-simpl-iterations` and noticed that the duplication happens through `efdtIntFB`s unfolding, which mentions `efdtIntUpFB` ''and'' `efdtIntDnFB`, which both want to inline their `c` later on. {{{ efdtIntFB = \ (@ r_a3cz) (c_a2ho :: Int -> r_a3cz -> r_a3cz) (n_a2hp :: r_a3cz) (x1_a2hq :: Int#) (x2_a2hr :: Int#) (y_a2hs :: Int#) -> case >=# x2_a2hr x1_a2hq of { __DEFAULT -> efdtIntDnFB @ r_a3cz c_a2ho n_a2hp x1_a2hq x2_a2hr y_a2hs; 1# -> efdtIntUpFB @ r_a3cz c_a2ho n_a2hp x1_a2hq x2_a2hr y_a2hs } }}} I'll see what we can do about that tomorrow... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 18:20:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 18:20:03 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.7c9d40d49838cdea36c3328f06ae9d72@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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): Phab:D4582 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"3cfb12d8adac37e5565d66fd173e4648cc041e65/ghc" 3cfb12d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cfb12d8adac37e5565d66fd173e4648cc041e65" In Exitify, zap idInfo of abstracted variables (fixes #15005) as helpfully outlined by SPJ. This commit copies a small bit code from `SetLevels` which could reasonably be put in `Id` as `zapAllIdinfo`; I did not do this to make merging this commmit into `ghc-8.4` easier. If this commit gets merged, then presumably after commit 3f59d3802170f495702674b4f8e4e80247803654 (test case) and ae0cff0a1834d8b041b06d0e1ab6ce969aac44c8 (other fixes to Exitify.hs). Differential Revision: https://phabricator.haskell.org/D4582 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 18:21:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 18:21:10 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.223a996faf857ab5b5a8ebc9e0b21c9d@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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): Phab:D4582 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: Pushed as 3cfb12d8adac37e5565d66fd173e4648cc041e65, should be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 19:25:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 19:25:12 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.759088e0066abac3e534ef8c8b6d22b7@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode, | 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 Azel): Looking a bit farther afield, all languages I see who have an `isAlphaNum` equivalent define it as returning `True` if either of their `isAlpha` or `isNumber` equivalents do (e.g. [https://docs.oracle.com/javase/9/docs/api/java/lang/Character.html #isLetterOrDigit-int- Java's], [http://msdn.microsoft.com/en- gb/library/cay4xx2f(v=vs.110).aspx the .NET Framework's], [http://www.lispworks.com/documentation/HyperSpec/Body/13_ade.htm Common Lisp's], [https://docs.python.org/3/library/stdtypes.html#str.isalnum Python's] — with the particularity in Python's documentation that they put three functions to match on numbers in `isalnum`'s description but the first two are subsumed by the third… — or [http://www.ada- auth.org/standards/12rm/html/RM-A-3-5.html Ada's]). So I'm willing to have a go at solving that ticket and would be in favour of fixing `u_iswalnum` and keeping the doc mostly as it is: it states that `isAlphaNum` selects alphabetic or numeric digit Unicode characters and currently, even if we remove the mark characters, it doesn't matches only that because it matches also `GENCAT_NO` and `GENCAT_NL`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 10 22:26:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Apr 2018 22:26:04 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.819b1be7411e9e0cb022ec39f90cae91@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: 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): With all due respect, if the CLC does not decide on a name, I feel like it should be @simonpj's decision, as the Libraries Mailing List could not decide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 06:41:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 06:41:00 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.a4422f562146e5f04b821ac75e242357@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: 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): We still need the allow-newer functionality though, as we don't want to see packages w/ `base < 4.13` hitting Hackage before GHC 8.6.1 is released! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 07:55:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 07:55:59 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change Message-ID: <045.1403435ab1f0de6522728d629c7153de@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Here it goes: {{{ ==== SUSPICIOUS CHANGES stm-delay: at nightly-2018-04-05-5161609117c16cb7b29b2b8b1cd41e74341d4137.csv build succeeded, 2 test suites passed, 0 test suites failed at nightly-2018-04-05-3cfb12d8adac37e5565d66fd173e4648cc041e65.csv build succeeded, 1 test suites passed, 0 test suites failed There are changes that need attention of GHC team. }}} This not necessarily indicates a bug or regression, but the fact is, between these two commits 1 test suite stopped building. Maybe it's worth some investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 08:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 08:10:27 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.79a58feeea2e513eab1c8a2565ea5ace@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): Version of stm-delay is 0.1.1.1, the version is determined by the build plan, nigthly-2018-04-05, found here: https://github.com/fpco/stackage-nightly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 08:54:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 08:54:23 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.2c55186036ba5142a08d1656a27f7ef6@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Another place where this could be useful is for abstracting the pattern in [https://hackage.haskell.org/package/base-4.11.0.0/docs/src/GHC.Enum.html#efdtIntUpFB efdt{Word,Int}{Up,Dn}FB]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 08:56:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 08:56:25 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.990f98c524e51e01d82257ed209e07e5@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): So, the difference is merely > 2 test suites passed, 0 test suites failed vs > 1 test suites passed, 0 test suites failed since for both cases, no test suites failed; does this mean that the test suite failed to build to due a compile failure, or that it merely wasn't even attempted to be built because no install-plan could be found? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:15:04 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.c79871656ea76a1f596a3671a6a191a0@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: 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): It would be nice to get that at some point. However, there has been no progress on this feature as far as I can tell, and I have several projects that are actively blocked by the inability to build `contravariant` on GHC HEAD, so I'm quite eager to move forward with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:23:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:23:35 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.48ea8f7414523b7372d7c4ce081ca096@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that's not a problem for `[x..y]` (`eftInt`), because that doesn't need to consider counting down. It's not an issue for `[x,y..]` (`edtInt`), because although it calls `efdtInt{Up,Dn}` internally, it doesn't take part in fusion at all (is that an oversight or by design?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:35:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:35:09 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.f957e3efd6769fa5f8fac1ff4e88632a@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, this ticket is incredibly vague. What exactly is going on here? Is this using GHC HEAD? GHC 8.4.1? Something else? The use of the phrase "nightly" does not tell me much. Also, you give commit hashes, which I can't tell are from GHC or `stm-delay`. Are these build logs hosted online somewhere? Is there a list of which packages are supposed to build and supposed to fail? (If this really //is// GHC HEAD, it would seem likely that you'd run into spurious failures more often.) How is it determined that this build failure is GHC's fault and not the fault of say, Stackage or a downstream dependency. In short, I'm totally lost. Some context here would be desperately appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:48:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:48:02 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.b847a973a387c70e49c2705ba71193b1@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Mark made a post to the devops list but not the main ghc-devs list which explains some more context. https://mail.haskell.org/pipermail/ghc-devops-group/2018-April/000182.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:49:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:49:15 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.ef305798cf39e435fc2acb1dbb628c7a@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): Sorry, for throwing it here without sufficient explanations. Here are some clarifications: https://mail.haskell.org/pipermail/ghc-devops-group/2018-April/000182.html And a blog post that describes everything in details is coming. If the sum of succeeding/failing test suites is decreases this indicates that some test suites failed to build. Hashes are GHC commit hashes on master branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 09:51:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 09:51:42 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.a8a9ee16a5262311413861439759ec62@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): > How is it determined that this build failure is GHC's fault and not the fault of say, Stackage or a downstream dependency? The build plan we use is fixed, so versions of packages and their dependencies cannot change. Any change observed is thus a result of some change in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 12:53:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 12:53:29 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.eb595ca6518ec011fd4fcc3d791e165e@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rjmk): I'm not sure I understand you correctly when you say > When we use rec in do blocks, rather than mdo blocks, the outer variables won't be included into the scope of rec block. so this may not be relevant, but removing the ApplicativeDo allows the code to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 13:13:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 13:13:33 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.aad0b4581aae796cf861ed5731067ed4@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I think the code in the description shouldn't be accept even without ApplicativeDo extension. Waiting for experts in this area to comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 14:53:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 14:53:15 -0000 Subject: [GHC] #15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release Message-ID: <042.4b53899d417f346d03c701660fddbf8b@haskell.org> #15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | 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: -------------------------------------+------------------------------------- Despite https://ghc.haskell.org/trac/ghc/ticket/14699#comment:25 it appears that GHC 8.4.1 shipped with bf4af114ba3d35b2937fc74926aa49e128dd6c1f (which doesn't correspond to any released version) instead of the expected `v2.2.2` tagged c7d396732bd45e409478bd4df1d0ca95d6f39356 commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 14:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 14:57:38 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.de224239302471d953d38cd348b9e3fb@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): One thing's that's utterly lost on me: How am I supposed to make any use of this by merely using cabal? ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:01:43 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.27ad4f9423eca6eeaa8861e8d20fd31b@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Perhaps another way of stating hvr's question is: are there logs available which show how these packages were built, and moreover, show what the build failure was? It would certainly save GHC developers some faffing about if there was a clear indication of //why// the package failed to build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:15:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:15:46 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.f7780cf6217d4ea8b85ef1f7b6586e81@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` (ready, > http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) > * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) > * `directory` (awaiting, https://github.com/haskell/directory/pull/79) > * `filepath` (ready, https://github.com/haskell/filepath/pull/67) > * `ghc-boot-th` (ready, in-place) > * `ghc-compat` (ready, in-place) > * `ghci` (ready, in-place) > * `haddock` (ready, > https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) > * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/81) > * `hpc` (ready, > http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) > * `parsec` (awaiting, https://github.com/haskell/parsec/pull/90) > * `process` (ready, https://github.com/haskell/process/pull/124) > * `stm` (awaiting, https://github.com/haskell/stm/pull/7) > * `template-haskell` (ready, in-place) > * `terminfo` (awaiting, https://github.com/judah/terminfo/pull/30) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` (ready, http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) * `directory` (ready, https://github.com/haskell/directory/pull/79) * `filepath` (ready, https://github.com/haskell/filepath/pull/67) * `ghc-boot-th` (ready, in-place) * `ghc-compat` (ready, in-place) * `ghci` (ready, in-place) * `haddock` (ready, https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/81) * `hpc` (ready, http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) * `parsec` (awaiting, https://github.com/haskell/parsec/pull/90) * `process` (ready, https://github.com/haskell/process/pull/124) * `stm` (ready, https://github.com/haskell/stm/pull/7) * `template-haskell` (ready, in-place) * `terminfo` (awaiting, https://github.com/judah/terminfo/pull/30) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:16:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:16:12 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.f9408a6325cedf3675b4b37271a380de@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: 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): At this point, the only libraries that are blocking progress on this are `haskeline`, `parsec`, and `terminfo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:28:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:28:36 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.1db25a05850030be1170e217bf66a38e@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Ah! You probably need to topologically sort those abs_vars; see the `sortQuantVars` call in SetLevels.abstractVars. A bug waiting to happen. While sleeping over it, I was wondering: Did I really get that wrong? And I checked: No, I did not! The `abs_vars` are derived from `captured`, and that is always in dependency order by construction. So no need for `sortQuantVars`. So I reverted the (unnecessary and hence misleading) use of `sortQuantVars` in 270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2, but left a comment that should prevent me from forgetting this again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:45:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:45:05 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.1bb3a31126fbdb34367be64ec773fb92@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I guess the process is not fully smoothed out yet, but that is expected. Nevertheless I want to say: **This is great! ** This is going to make GHC development much more robust and better! > The build takes about one hour. Wow, that’s much less than I thought. that’s faster than `perf.haskell.org`… Can we run it on every commit then? Or, maybe a bit less wasteful: Run it every few hours, but if there is a difference, then automatically schedule additional runs of the commits in between to bisect the change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 15:49:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 15:49:30 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.572007d97432a3fd03e41f0124b56818@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Case in point for why build logs are critical here: I just tried running the test suites for `stm-delay-0.1.1.1` using commit 3cfb12d8adac37e5565d66fd173e4648cc041e65 using a standard: {{{ $ cabal configure -w ~/Software/ghc/inplace/bin/ghc-stage2 --enable-tests $ cabal test }}} And both test suites successfully built and ran for me. So clearly `stackage-head` is doing something different, but I have no idea what that could be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 16:00:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 16:00:05 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.03a5c4e87221e2c43af8c911f4ffe773@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | Phab:D4486 -------------------------------------+------------------------------------- Comment (by alpmestan): I'm seeing the following failures with commit 8b823f270e: {{{ /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870b.run T12870b [bad heap profile] (profasm) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870c.run T12870c [bad heap profile] (profasm) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profasm) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profthreaded) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profasm) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870h.run T12870h [bad heap profile] (profasm) /run/user/1001/ghctest-9vjo4opa/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profthreaded) }}} Could someone else try to run those tests with those `WAY`s and let me know if they see the same failures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 16:07:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 16:07:13 -0000 Subject: [GHC] #14912: UnsafeReenter test fails with threaded1 and threaded2 In-Reply-To: <048.0d06801876b264a33d0020ade629babb@haskell.org> References: <048.0d06801876b264a33d0020ade629babb@haskell.org> Message-ID: <063.7f13ae7df56d38b7c001b7ee49b0ead2@haskell.org> #14912: UnsafeReenter test fails with threaded1 and threaded2 -----------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 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 alpmestan): I'm now seeing it hang with the `profthreaded` way as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 16:41:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 16:41:30 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 Message-ID: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- As said, is it possible to switch to llvm-toolchain-6.0 for the next 8.6.x release? I don't know if it is already ongoing, but I would like to track progresses to understand when to switch in Debian, or cherry-pick patches and rebase on top of 8.4.1 (currently in experimental, using 5.9) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 17:18:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 17:18:33 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.433281c13d6b2531022b747cb2a92a5d@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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): Replying to [comment:6 goldfire]: > With the `Foo` in comment:3, this also panics: It does? I must be doing something wrong, since this appears to compile for me: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data Foo (x :: Type) :: forall (a :: x). Proxy a -> Type quux :: forall x arg. Proxy (Foo arg) -> Maybe x quux = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 17:26:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 17:26:00 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.a6d9caea6595884bcd52599d5302f615@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.5 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 RyanGlScott): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 17:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 17:33:24 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.a55ded1c3892ee8cfee41ef6987b8ca2@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mrkkrp): Good points about the logs. Right now we use information that stackage- curator gives us which isn't plenty. This probably can be improved. I'll investigate the std-delay failure tomorrow and if necessary download the actual logs from the cache. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 17:46:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 17:46:40 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.0804671082d135db24a1a8b343655637@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regardless of what happens with this particular ticket, I would like to reiterate nomeata's message: this sort of tooling is long overdue. Thank you for picking this up, mrkkrp! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 17:53:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 17:53:40 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.aab22945ba83f8f00dd4292425d6a86d@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:9 nomeata]: > > The build takes about one hour. > > Wow, that’s much less than I thought. It's only building a bit more than half of all Stackage Nightly right now, because 5 packages currently fail and those are dependencies for the rest. We expect that all told, on the "xlarge" CircleCI machine types, a full Stackage build should take around 2 hours. That's just an extrapolation though. Reality might be quite a bit worse (or better). > that’s faster than `perf.haskell.org`… Can we run it on every commit then? > > Or, maybe a bit less wasteful: Run it every few hours, but if there is a difference, then automatically schedule additional runs of the commits in between to bisect the change? It's currently set at running every 6 hours, and only using GHC master. But I agree, running it at every commit could well be viable. Let's iterate on this as we get more experience using it. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 18:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 18:29:15 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.4812d730af9e50b7701a1ace74b3a6ad@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I have no strong preference, but Simon's suggestion of `Solo#` sounds good to me. Keeping the hash in seems consistent with the rest of the constructors for kind `#` and so feels like a good idea. It would also let folks consistently use `Solo` for the `data`-based unary tuple if they wanted it in user-space somewhere. e.g. That is an example of something that admits a legal `MonadFail` (unlike `Identity`) but not recovery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 18:35:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 18:35:09 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.743cdb118e4c875b021521aeae4e55af@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I cannot build my ray-tracer with the new GHC version, but I'll try to fix problems and get back here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 18:48:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 18:48:45 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 In-Reply-To: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> References: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> Message-ID: <067.e45856b9d6811362d033b53b85768517@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: angerman (added) Comment: Moritz Angerman is probably best equipped to comment on this at the moment. As far as I know the last few LLVM upgrades have gone pretty smoothly so this should be able to happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 19:36:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 19:36:00 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations Message-ID: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | 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: -------------------------------------+------------------------------------- There are currently a handful of `@since TODO` annotations in Haddocks throughout the core libraries that were probably intended to be replaced with a real version at some point, but managed to slip through the cracks into the GHC 8.4.1 release: * `FixIOException` in `base`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries/base/GHC/IO/Exception.hs#l276 * `powModSecInteger` in `integer-gmp`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries /integer-gmp/src/GHC/Integer/Type.hs#l1454 We should fix these before GHC 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 19:36:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 19:36:34 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.acee53c6235508f11f757e4f8b0d16e4@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4578 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 20:49:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 20:49:26 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.844dbba74dee49a35b3483d74c83b4f2@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D4578 => Phab:D4578, Phab:D4586 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 21:38:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 21:38:52 -0000 Subject: [GHC] #15026: Type deduction panic Message-ID: <045.35de2755e3ca39f992d513b2c5f4e290@haskell.org> #15026: Type deduction panic -------------------------------------+------------------------------------- Reporter: moomin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!lhs > {-# LANGUAGE DeriveFunctor #-} > module Bug where > import qualified Data.Set as S > import Data.Foldable (fold, foldMap, toList) > import Data.List.Split (splitOn) > import Data.Monoid -- ((<>), Sum, mempty, mappend) > import Data.Functor.Foldable > newtype Component = Component (Int,Int) deriving (Eq, Ord, Show) > data Day24State v a = Day24State { > valueToMatch :: Int, > componentsToUse :: S.Set Component, > componentMetric :: v, > nextStates :: [a] > } deriving (Functor, Show) > type Day24StateFix v a = Fix (Day24State v) }}} Now in GHCI type > :t Data.Functor.Foldable.ana f (undefined :: Day24StateFix Component) Produces ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] f_akbJ :: t_akbI[tau:3] (CHoleCan: f)} 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 Wed Apr 11 21:40:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 21:40:02 -0000 Subject: [GHC] #15026: Type deduction panic In-Reply-To: <045.35de2755e3ca39f992d513b2c5f4e290@haskell.org> References: <045.35de2755e3ca39f992d513b2c5f4e290@haskell.org> Message-ID: <060.88eaee79309ed83b4d8ed6d127cc4b68@haskell.org> #15026: Type deduction panic -------------------------------------+------------------------------------- Reporter: moomin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: I think this bug will be fixed in a more recent GHC version. 8.2.2 or 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 23:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 23:01:37 -0000 Subject: [GHC] #15027: Remove WrappedMonad from Control.Applicative Message-ID: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> #15027: Remove WrappedMonad from Control.Applicative -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: base | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a data type `WrappedMonad` in `Control.Applicative`. It provides an `Applicative` instance for a type based on the `Monad` instance. This type hasn't been useful since AMP landed in GHC 7.10 about three years ago. I propose that this type be marked deprecated in GHC 8.6 and then removed in GHC 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 23:07:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 23:07:02 -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.19c45ae593fcc433d1dddcdb212c0b0c@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Phab:D4440 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 23:09:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 23:09:30 -0000 Subject: [GHC] #14987: Memory usage exploding for complex pattern matching In-Reply-To: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> References: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> Message-ID: <062.49f74803006ddbc23fee184c9925a948@haskell.org> #14987: Memory usage exploding for complex pattern matching -------------------------------------+------------------------------------- Reporter: vmiraldo | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The patch that triggered this has been reverted. However, this is just a workaround; ultimately we will want to apply this patch again as it fixed #14838. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 11 23:10:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Apr 2018 23:10:17 -0000 Subject: [GHC] #14947: internal error: Invalid object *c in push() In-Reply-To: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> References: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> Message-ID: <060.490e321dad7650fbac4d545160e3277a@haskell.org> #14947: internal error: Invalid object *c in push() -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 00:00:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 00:00:26 -0000 Subject: [GHC] #15028: Deprecate and Remove Data.Semigroup.Option Message-ID: <049.03897d3322661841e0dfff5e5126841a@haskell.org> #15028: Deprecate and Remove Data.Semigroup.Option -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: base | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the Semigroup-Monoid Proposal has landed, the data type `Option` from `Data.Semigroup` is now obsolete. I propose that it be marked deprecated in GHC 8.6 and removed in GHC 8.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 06:25:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 06:25:53 -0000 Subject: [GHC] #15029: haddock parsing fails with valid input Message-ID: <045.21dff08a6f5f54f4b5d46444a13b9eee@haskell.org> #15029: haddock parsing fails with valid input -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reported here: https://github.com/haskell/haddock/issues/798 This is really a GHC parsing issue, even though it only shows up in the haddock "route." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 08:09:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 08:09:11 -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.f519c8ba4f9ff6444bcd3502daa51597@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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 simonmar): The error is an internal error in the runtime system or compiled code, and doesn't tell us very much unfortunately. A wide variety of different kinds of problems can lead to this symptom. I'm not aware of any known bugs in this area. To narrow this down we'll need to be able to reproduce it and debug it. Anything you could do to produce a standalone reproduction for the bug would be really helpful. Failing that if you could provide a binary and a core dump, that might also let us dig around and get more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 08:49:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 08:49:39 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.62c967d762c67bb41798442a010043e1@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | Phab:D4486 -------------------------------------+------------------------------------- Comment (by alpmestan): The aforementionned failures are addressed by Andreas in [https://phabricator.haskell.org/D4585 D4585]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 09:28:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 09:28:27 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.dc029f8e1742b0594af2e60418987d7c@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Here's an implementation of `efdtIntFB` that fits our requirements: {{{ data Direction = Up | Dn deriving Eq direction :: Int# -> Int# -> Direction direction from to | isTrue# (to >=# from) = Up | otherwise = Dn efdtIntFB :: (Int -> r -> r) -> r -> Int# -> Int# -> Int# -> r efdtIntFB c n x1 x2 y = emit first x1 where -- We can safely emit the first element if an iteration -- 'moves closer' to @y at . That's exactly the case when -- @dir_x2@ coincides with @dir_y at . !first = dir_x2 == dir_y !dir_x2 = direction x1 x2 !dir_y = direction x1 y -- We need the overflow flag in 'emit'. (# delta, delta_ovf #) = x2 `subIntC#` x1 -- | Think of @emit :: Maybe Int -> [Int]@, only unboxed. -- If the argument is 'Nothing', we reached the end of the list. -- If the argument is 'Just', we emit an element, compute -- the next candidate, validate it and recurse. emit False _ = n emit True x = I# x `c` emit next_ok next where -- Check that @next@ didn't move past @y at . -- Also, overflow is only allowed iff the computation for -- @delta@ overflowed. (# next, next_ovf #) = addIntC# x delta !next_ok = isTrue# (next_ovf ==# delta_ovf) && direction next y == dir_y -- TODO: evaluate strict && for branchless code {-# INLINE[0] efdtIntFB #-} }}} Some pros: - I find this much easier to understand. No complicated invariants, etc. - No Up/Dn variants to maintain. Still, if the direction is statically known, constant folding and inlining will simplify stuff to the equivalent code. - As a result, no more duplication of `c` occurrences - Also no more duplication of `n` occurrences Cons: - `emit`s closure is 4 words big (2 words bigger than the closure of the original `go_up` helper) in the most general form. It's unfortunate that we can't pack together `dir_y` and `delta_ovf` into a single word without confusing constant folding. This would need either some kind of constant propagation through bit fields (out of scope for GHC, I think) or a smarter closure allocation theme that packs together non-pointer payloads. - We pay for the generalisation of Up/Dn variants by having to compare with `dir_y` all the time. - `base` lacks `addWordC#` primitives, which I'll probably add now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 09:39:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 09:39:02 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.656de4c87ab8560ff776e0697652d163@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I'm seeing a failure for `profasm` as well with a recent checkout of the master branch (commit 8b823f270e), with the simplifier tick limit error. If we increase the limit, we run out of stack space. If we increase the stack size enough with -K, we run out of simplifier ticks again. I'll mark the test as expected broken with the `profasm` way, but this does look rather suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 09:42:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 09:42:49 -0000 Subject: [GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted In-Reply-To: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> References: <045.15a50e8cf09d238432f3c8dd9d5144ad@haskell.org> Message-ID: <060.4ae6ba743f8b1d47862396fbc5140584@haskell.org> #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: simplifier | ticks Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: dynamic-paper 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 Thu Apr 12 10:31:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 10:31:30 -0000 Subject: [GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent In-Reply-To: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> References: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> Message-ID: <059.44cbef7fe746418bfef89198167dd185@haskell.org> #14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Ping? I'd like to know whether this is considered to be a bug. (The question arises because the GHC API has no stability guarantees, and apperently the current behavior is enough for ghci to work. On the other hand, specifying and loading targets by filename incrementally can be quite useful, and it used to work.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 11:37:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 11:37:18 -0000 Subject: [GHC] #7606: Stride scheduling for Haskell threads with priorities In-Reply-To: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> References: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> Message-ID: <060.673da2b50125d9fe8f839e433efae76e@haskell.org> #7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 11:42:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 11:42:24 -0000 Subject: [GHC] #15030: Cabal Installation error in Windows 10 machine for Haskell Message-ID: <046.a36e2868381831475a2318fc7d87e055@haskell.org> #15030: Cabal Installation error in Windows 10 machine for Haskell --------------------------------+---------------------------- Reporter: gavinnf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------- When installing Haskell in my Windows 10 machine and executing the following at GitBash MinGw64 prompt $ cabal install doctest hindent stylish-haskell tasty tasty-hunit tasty- quickcheck codeworld-api The error attached displayed after the installation . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 11:44:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 11:44:00 -0000 Subject: [GHC] #15030: Cabal Installation error in Windows 10 machine for Haskell In-Reply-To: <046.a36e2868381831475a2318fc7d87e055@haskell.org> References: <046.a36e2868381831475a2318fc7d87e055@haskell.org> Message-ID: <061.77a021ad4b94d0a992c2db0643cc605a@haskell.org> #15030: Cabal Installation error in Windows 10 machine for Haskell -----------------------------+------------------------------ Reporter: gavinnf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+------------------------------ Changes (by gavinnf): * Attachment "rrortobereported.GIF" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 13:34:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 13:34:32 -0000 Subject: [GHC] #15031: [1,1..0] /= [1,1..2] Message-ID: <044.0952e700ddcfc2a48a30a84327a0a3cd@haskell.org> #15031: [1,1..0] /= [1,1..2] -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm currently refactoring `efdtIntFB` into something that fuses better (#8763). While testing my prototype, I noticed that in current base `[1,1..x]` for `x` < 1 has different behavior than I expected: `[1,1..0] == []`. In comparison, the `x` == 1 or > 1 case yields `repeat 1`. Is this expected and/or specified somewhere? If so, I find this rather surprising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 13:50:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 13:50:08 -0000 Subject: [GHC] #15031: [1,1..0] /= [1,1..2] In-Reply-To: <044.0952e700ddcfc2a48a30a84327a0a3cd@haskell.org> References: <044.0952e700ddcfc2a48a30a84327a0a3cd@haskell.org> Message-ID: <059.d6f7f140c44f6150c1b451c26684b588@haskell.org> #15031: [1,1..0] /= [1,1..2] -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Ok, found it in section 6.3.4 of the Haskell2010 spec: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#dx13-131001 > The sequence enumFromThenTo e1 e2 e3 is the list [e1,e1 + i,e1 + 2i,…e3], where the increment, i, is e2 − e1. If the increment is positive or zero, the list terminates when the next element would be greater than e3; the list is empty if e1 > e3. If the increment is negative, the list terminates when the next element would be less than e3; the list is empty if e1 < e3. Since the increment is in fact 0 and e3=0 < e1=1, this conforms to the standard. What an unfortunate assymetry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 13:50:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 13:50:44 -0000 Subject: [GHC] #15031: [1,1..0] /= [1,1..2] In-Reply-To: <044.0952e700ddcfc2a48a30a84327a0a3cd@haskell.org> References: <044.0952e700ddcfc2a48a30a84327a0a3cd@haskell.org> Message-ID: <059.feb5a6d9cc18f67de891fe8c082fb6c3@haskell.org> #15031: [1,1..0] /= [1,1..2] -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 14:02:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 14:02:53 -0000 Subject: [GHC] #14964: performance regressions from 8.0.2 to 8.4.1 In-Reply-To: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> References: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> Message-ID: <062.b9983d2f9c58601c50934ad2075f22fd@haskell.org> #14964: performance regressions from 8.0.2 to 8.4.1 -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 14:30:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 14:30:14 -0000 Subject: [GHC] #15030: Cabal Installation error in Windows 10 machine for Haskell In-Reply-To: <046.a36e2868381831475a2318fc7d87e055@haskell.org> References: <046.a36e2868381831475a2318fc7d87e055@haskell.org> Message-ID: <061.f2e4febd41dca6d252203e4361fdfb55@haskell.org> #15030: Cabal Installation error in Windows 10 machine for Haskell -----------------------------+------------------------------ Reporter: gavinnf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+------------------------------ Changes (by hvr): * version: 8.2.2 => 8.2.1 Comment: I believe this issue only occured before GHC 8.2.2, i.e. w/ GHC 8.2.1; but in GHC 8.2.2 it shouldn't occur anymore -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 15:03:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 15:03:07 -0000 Subject: [GHC] #15030: Cabal Installation error in Windows 10 machine for Haskell In-Reply-To: <046.a36e2868381831475a2318fc7d87e055@haskell.org> References: <046.a36e2868381831475a2318fc7d87e055@haskell.org> Message-ID: <061.9c1454555ac6f8eccda0fb35329a3425@haskell.org> #15030: Cabal Installation error in Windows 10 machine for Haskell ------------------------------+------------------------------ Reporter: gavinnf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14393 | Differential Rev(s): Wiki Page: | ------------------------------+------------------------------ Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14393 Comment: Closing as a duplicate of #14393 (which was fixed in GHC 8.2.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 15:30:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 15:30:43 -0000 Subject: [GHC] #7606: Stride scheduling for Haskell threads with priorities In-Reply-To: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> References: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> Message-ID: <060.aa94d9178428a17f76e73a6986152c27@haskell.org> #7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Currently, GHC uses a round-robin scheduler for Haskell threads, with > some heuristics for when threads should be bumped to the front of the > queue. This patch set replaces this scheduler with 'stride scheduling', > as described by Waldspurger and Weihl '95, which is an efficient, > deterministic method for scheduling processes with differing priorities. > Priorities are assigned by giving 'tickets' to threads; a thread with > twice as many tickets as another will run twice as often. I’d like to > replace the round-robin scheduler completely with this scheduler. > > Here are nofib benchmarks comparing the old scheduler to the new: > > {{{ > -------------------------------------------------------------------------------- > Program Size Allocs Runtime Elapsed TotalMem > -------------------------------------------------------------------------------- > Min -0.0% -52.2% -18.8% -18.6% -83.1% > Max +1.0% +4.2% +4.9% +5.1% +7.7% > Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% > }}} > > Here are some technical details: > > * Without any changes to ticket values, scheduling behavior should be > functionally identical to round-robin. (By default, new threads, > including the IO thread, get allocated the max nubmer of tickets > possible.) This is not quite identical, since our heap does not have FIFO > property (see below.) > > * The current patch-set uses a very simple (e.g. undergrad level) > resizable-array backed heap to implement the priority queue; we can play > some tricks to reduce the memory footprint of the priority queue (e.g. > using the container_of macro to eliminate the extra keys store); and a > more fancy data structure would make it easier for us to surgically > remove entries or reweight them, but I wanted to keep overhead low. If > anyone has a pet implementation of priority queues in C feel free to swap > it in. Right now, this only affects the uses of promoteInRunQueue() in > Messages.c; I still need to check if #3838 has regressed. > > * We get three new primops: `setTickets#`, `getTickets#` and > `modifyTickets#`. We don't support creating threads with specific numbers > of tickets (mostly because that would have added an annoyingly large set > of extra primops); instead, you're expected to spawn a thread which gets > max-ticket allocation, and then weight it down. > > * `_link` is no longer used for linking TSOs in the run queue. I have > tried my best to stamp out any code which operated on this assumption, > but I may have missed some. > > * Modifying a TSO's tickets takes out the scheduler lock; the hope is > that this operation is quick and rare enough that a global lock here is > not too bad. > > * We are unfortunately stuck with some magic constants w.r.t. ticket > values: 1 << 20 is the maximum number of tickets our implementation is > hard-coded to support. > > * Sleeping and blocked tasks do not get any 'bonus' for being blocked. > > * In an ideal world, when a thread hits a black hole, it should > temporarily give its tickets to the thread evaluating the black hole, so > it will unblock more quickly. Unfortunately, implementing this is pretty > complicated (the blackhole evaluating thread could die; or it could get > stuck on a blackhole itself and need to gift its tickets; it shouldn't be > able to give away the tickets it was gifted.) So this implementation > leaves that out. Similar semantics for MVars are probably possible, but > will require userland assistance too. > > I haven't prepared a patch to base yet with a user-level API, but here is > a proposed draft: > > {{{ > type Tickets = Int > > -- | Maximum number of tickets we support a thread having. (Currently 2 > >> 20) > -- Note that this doesn't bound the *global* maximum tickets. > maxTickets :: Tickets > > -- | Changes the number of tickets allocated to a thread. The ticket > count must > -- not be less than or equal to zero, or greater than maxTickets. > (Corresponds > -- to setTickets# primop) > setTickets :: ThreadId -> Tickets -> IO () > > -- | Returns the number of tickets currently allocated to a thread. > (Corresponds to > -- getTickets# primop) > getTickets :: ThreadId -> IO Tickets > > -- | Atomically performs a linear transformation on the number of tickets > a thread; > -- e.g. scaling the number of tickets by a rational number, adding > another fixed > -- set of tickets, and then returning the number of 'leftover' tickets > from the operation; e.g. > -- if the net amount of tickets is reduced, then the returned result is > positive; > -- if the net amount of tickets is increased, the returned result is > negative. > -- In the absence of concurrent threads, the following property holds > forall > -- t, m and x: > -- > -- do r <- getTickets t > -- d <- scaleTickets t m x > -- r' <- getTickets t > -- return (r == r' + d) > -- > -- If the scaling would reduce the number of tickets below zero or > increase the > -- number of tickets beyond maxTickets, this function will instead fail > with > -- an exception. This function will be subject to some rounding error; > powers of two > -- are, however, likely to be exact. (Corresponds to modifyTickets# > primop; note > -- that the sentinel value for failure is maxTickets + 1, since it is > impossible for > -- a thread's ticket value to change by that much.) > modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets > > -- | Forks a new thread, transferring some percentage of tickets from the > current > -- thread to it (so the net number of tickets stays constant.) Fails if > the rational > -- is greater than 1 or less than or equal to zero, or if there are not > enough tickets > -- in the current thread. > forkIOWith :: IO a -> Ratio Int -> IO ThreadId > > }}} New description: Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by [http://read.seas.harvard.edu/~kohler/class/aosref/waldspurger95stride.pdf Waldspurger and Weihl '95], which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round- robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:14:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:14:55 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives Message-ID: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> #15032: GHCi panics when attempting to load archives --------------------------------------+------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Common }}} (with a file libnumertheory.a is in ../dist-newstyle/lib) I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported 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 Thu Apr 12 16:16:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:16:07 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.7604afdbf0e4b3b43c9bf735ec786d9c@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Description changed by vanessamchale: Old description: > If I have the following module: > > {{{#!hs > module Numeric.Integer ( is_prime_ats > ) where > > import Foreign.C > > foreign import ccall is_prime_ats :: CInt -> CBool > }}} > > and I attempt to open it in GHCi with the following > > {{{ > /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib > Numeric.Common > }}} > > (with a file libnumertheory.a is in ../dist-newstyle/lib) > > I get a panic and a request to open a bug report. I am guessing that at > the least this supposed to be a different error message. > > {{{ > GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > Loading archives not supported > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Common }}} (with a file `libnumertheory.a` in `../dist-newstyle/lib`) I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported 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 Thu Apr 12 16:36:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:36:09 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.17c713868efc0d83fa5316e244e5f928@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Description changed by vanessamchale: Old description: > If I have the following module: > > {{{#!hs > module Numeric.Integer ( is_prime_ats > ) where > > import Foreign.C > > foreign import ccall is_prime_ats :: CInt -> CBool > }}} > > and I attempt to open it in GHCi with the following > > {{{ > /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib > Numeric.Common > }}} > > (with a file `libnumertheory.a` in `../dist-newstyle/lib`) > > I get a panic and a request to open a bug report. I am guessing that at > the least this supposed to be a different error message. > > {{{ > GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > Loading archives not supported > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Common }}} (with a file `libnumertheory.a` in `../dist-newstyle/lib`) If I instead place a shared library (i.e. `libnumbertheory.so`) in `../dist-newstyle/lib`) then this does not panic. I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported 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 Thu Apr 12 16:37:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:37:49 -0000 Subject: [GHC] #14708: GHC panics when linking with an archive and using an annotation In-Reply-To: <046.3ba93269311e390d484d95c8a405c373@haskell.org> References: <046.3ba93269311e390d484d95c8a405c373@haskell.org> Message-ID: <061.9926c9961668a2621dd7684863a5c62e@haskell.org> #14708: GHC panics when linking with an archive and using an annotation -------------------------------------+------------------------------------- Reporter: tchajed | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #9438 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Note that the `ANN` is not critical to reproduce this bug. You can just as well remove it and instead load `app.hs` with `ghci` to trigger the bug as well: {{{ $ ghci -ladd -L. app.hs GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In other words, the key sticking point is not the use of `ANN`, but rather loading archives in interpreted code in general. Therefore, this is a duplicate of #9438, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:37:52 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.2bd0f1c483ac84af252e3045fd493d07@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Description changed by vanessamchale: Old description: > If I have the following module: > > {{{#!hs > module Numeric.Integer ( is_prime_ats > ) where > > import Foreign.C > > foreign import ccall is_prime_ats :: CInt -> CBool > }}} > > and I attempt to open it in GHCi with the following > > {{{ > /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib > Numeric.Common > }}} > > (with a file `libnumertheory.a` in `../dist-newstyle/lib`) > > If I instead place a shared library (i.e. `libnumbertheory.so`) in > `../dist-newstyle/lib`) then this does not panic. > > I get a panic and a request to open a bug report. I am guessing that at > the least this supposed to be a different error message. > > {{{ > GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > Loading archives not supported > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Common }}} (with a file `libnumertheory.a` in `../dist-newstyle/lib`) I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If I instead place a shared library (i.e. `libnumbertheory.so`) in `../dist-newstyle/lib`) then this does not panic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:38:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:38:40 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.0edeefb2e8009a675bcb8302649c4eb9@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #9438 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #9438 Comment: This is a duplicate of #9438, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:39:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:39:41 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.69850f79a6f7685c19f4bb9596a7c80e@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that the use of interpreted code (either with `ghci`, as in this example, or with `ANN`, as in #14708) is needed to trigger the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:42:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:42:34 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.65b9c632e7b6ce286e91453080308392@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): #15032 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * failure: Other => GHCi crash * component: Compiler => Compiler (Linking) * architecture: x86_64 (amd64) => Unknown/Multiple * related: #8164, #14708 => #8164, #14708, #15032 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:42:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:42:49 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.f141207e62affcc481b0ad8714eaa97b@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by vanessamchale): * related: #9438 => Old description: > If I have the following module: > > {{{#!hs > module Numeric.Integer ( is_prime_ats > ) where > > import Foreign.C > > foreign import ccall is_prime_ats :: CInt -> CBool > }}} > > and I attempt to open it in GHCi with the following > > {{{ > /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib > Numeric.Common > }}} > > (with a file `libnumertheory.a` in `../dist-newstyle/lib`) > > I get a panic and a request to open a bug report. I am guessing that at > the least this supposed to be a different error message. > > {{{ > GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > Loading archives not supported > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > If I instead place a shared library (i.e. `libnumbertheory.so`) in > `../dist-newstyle/lib`) then this does not panic. New description: If I have the following module: {{{#!hs module Numeric.Integer ( is_prime_ats ) where import Foreign.C foreign import ccall is_prime_ats :: CInt -> CBool }}} and I attempt to open it in GHCi with the following {{{ /opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Integer }}} (with a file `libnumertheory.a` in `../dist-newstyle/lib`) I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message. {{{ GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If I instead place a shared library (i.e. `libnumbertheory.so`) in `../dist-newstyle/lib`) then this does not panic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 16:58:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 16:58:32 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.12d1c50969d4b724936ee0de63b1ce91@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): #15032 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm quite unclear if this is intended behavior or not. This behavior was introduced in commit 83f5c6c69ceeff6cb6ca8d56dfad79c5e126a130 (`When dynamic-by-default, don't use the GHCi linker`), which gives the rationalization: > When dynamic-by-default, don't use the GHCi linker I'm not sure if this was supposed to apply to //user-supplied// archive files, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 17:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 17:45:11 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.7d4a8d651eb580fcf383887f43793ad1@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4589 Comment: After talking to Phyx-, this should indeed be an error. I've created Phab:D4589 to turn this panic to an error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 17:51:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 17:51:10 -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.1cc7c6904937ff873299da15a5873869@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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 ramirez7): Just saw the error happen again. I'll investigate the server to see if I can find any more artifacts. We did find some extra logs in {{{messages}}}: {{{ Apr 12 09:43:07 stdouterr.log: binary-name-elided: internal error: TSO object entered! Apr 12 09:43:07 stdouterr.log: (GHC version 8.0.2 for x86_64_unknown_linux) Apr 12 09:43:07 stdouterr.log: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Apr 12 09:43:07 messages: Apr 12 16:43:07 ip-10-10-28-23 kernel: [413908.905615] traps: ghc_worker[23036] general protection ip:7f5b72a24196 sp:7f5b64de2c10 error:0 Apr 12 09:43:07 messages: Apr 12 16:43:07 ip-10-10-28-23 kernel: [413908.911110] in libc-2.23.so[7f5b729ed000+1c0000] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 22:37:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 22:37:47 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.203ae85d2a610b4ce63018f0e3d1e4e5@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: TypeFamilies, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies => TypeFamilies, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 12 22:37:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Apr 2018 22:37:57 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.f87c3dff6f684d8a7c8a068f995a7f59@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: TypeFamilies, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T8165, | deriving/should_fail/T8165_fail1, | deriving/should_fail/T8165_fail2 Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies => TypeFamilies, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 02:23:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 02:23:12 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.e6ef6fbe6dbf621a01db7dd8308701ef@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.5 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 goldfire): I think we need these invariants: 1. If `ty <- tc_hs_type ... exp_kind`, then `typeKind ty == exp_kind`. 2. If `(ty, ki) <- tc_infer_hs_type ...`, then `typeKind ty == ki`. 3. If `(ty, ki) <- tc_infer_hs_type ...`, then `zonk ki == ki`. 4. If `(ty, ki) <- tcTyVar ...`, then `typeKind ty == ki`. 5. If `(ty, ki) <- tcTyVar ...`, then `zonk ki == ki`. All of these appear to be true now, except I'm worried about the `tcTyVar` case for `TcTyCon`s -- I ''think'' `TcTyCon` kinds can have unzonked metavariables, if the `TcTyCon` comes from the non-CUSK case in `kcLHsQTyVars`. Do you also think this is possible? If so, we need to zonk the kind and wrap the (knot-tied) type in a reflexive coercion (with `mkNakedCastTy`) to fix its kind. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 04:35:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 04:35:03 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.4a573e85bbeb67e6cc1baf3cc40f348a@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Running with a development build of either 8.2.2 or 8.4ish (I haven't checked others yet) turns up an interesting warning when compiling `Paper.hs`: the simplifier bails out after 4 iterations. So it seems at least ''possible'' that whatever goes wrong in `Main.hs` may start in `Paper.hs`, if we end up with incompletely simplified unfoldings. One problem I'm facing is that this source code is ... not very simple. It's full of rather involved constraint-based programming that's presumably documented in a paper somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 04:52:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 04:52:09 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.f9e3acc11012c7c547fe9f8d0a249907@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #9438 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by dfeuer): * related: => #9438 Comment: I think the related tickets field probably got wiped by mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 07:15:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 07:15:06 -0000 Subject: [GHC] #15022: Stackage HEAD detected a suspicious change In-Reply-To: <045.1403435ab1f0de6522728d629c7153de@haskell.org> References: <045.1403435ab1f0de6522728d629c7153de@haskell.org> Message-ID: <060.efce518e55ee31cd9f45938fc7c5e988@haskell.org> #15022: Stackage HEAD detected a suspicious change -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 mrkkrp): * status: new => closed * resolution: => invalid Comment: It looks like this was a false alarm. I re-run the script with the older GHC bindist and got single test suite run. Something has changed but the change is not caused by GHC. So, one test suite (test-threaded) is not run anymore for unknown reason. The other test suite (test) is run. They are almost identical BTW: {{{ test-suite test type: exitcode-stdio-1.0 hs-source-dirs: test main-is: Main.hs ghc-options: -Wall -fno-warn-missing-signatures -fno-warn-name-shadowing -fno-warn-unused-do-bind -fno-warn-unused-matches build-depends: base >= 4.3 && < 5 , stm , stm-delay test-suite test-threaded type: exitcode-stdio-1.0 hs-source-dirs: test main-is: Main.hs ghc-options: -Wall -threaded -fno-warn-missing-signatures -fno-warn-name-shadowing -fno-warn-unused-do-bind -fno-warn-unused-matches build-depends: base >= 4.3 && < 5 , stm , stm-delay }}} There was also a bug in detection of failing packages (those that failing not during building but during configuration step were not included in the report at all), there 27 failing packages, but this is not relevant in this case. I have adjusted the setup to exclude any changes but those introduced by GHC: * We previously downloaded `stack` in binary form on every run without controlling whether it's the same `stack` every time. `stack` binary is now fixed and cannot change between runs. * The same for `stackage-curator`. * The docker image we used `snoyberg/stackage:nightly` also changes frequently and so I created a different image that I won't update unless needed. * We previously run `stack update` on every execution of the script, which may have affected the results. I included this command in `Dockerfile` instead so updates of Hackage indices are controlled as well. This should eliminate influence of external factors on results that we observe. So, again, sorry for the false alarm! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 14:35:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 14:35:07 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.ba664ae368004e79ff16a28664241b2f@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 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 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * related: #5321, #11598, #12506 => #5321, #11598, #12506, #13386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:06:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:06:18 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.90fde2e76f275fc1f49f77079bd67807@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c4814ab6b8d756ae0e32c9a9f44e4888c4e24763/ghc" c4814ab6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c4814ab6b8d756ae0e32c9a9f44e4888c4e24763" Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 This takes care of bumping the `base` and `integer-gmp` minor version numbers in anticipation of a GHC 8.4.2 release. While I was in town, I also filled in a `@since TODO` Haddock annotation for `powModSecInteger` in `integer-gmp` with `1.0.2.0`, and updated the changelog accordingly. Test Plan: ./validate Reviewers: hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15025 Differential Revision: https://phabricator.haskell.org/D4586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:06:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:06:48 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.97dcaf472520628f9c3d485398abb512@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"78ff6e541d33d2d2caf52d2cb4578cd7b745d282/ghc" 78ff6e54/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="78ff6e541d33d2d2caf52d2cb4578cd7b745d282" Revert "CmmPipeline: add a second pass of CmmCommonBlockElim" This reverts commit d5c4d46a62ce6a0cfa6440344f707136eff18119. Please see #14989 for details. Test Plan: ./validate Reviewers: bgamari, simonmar Subscribers: thomie, carter GHC Trac Issues: #14989 Differential Revision: https://phabricator.haskell.org/D4577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:07:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:07:03 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.79c339ba286a5d27d0336f10cb4c75cd@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a303584e58b3f4791bc5881cb722e7f498e14554/ghc" a303584e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a303584e58b3f4791bc5881cb722e7f498e14554" Fix processHeapClosureForDead CONSTR_NOCAF case: CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Reviewers: bgamari, simonmar, erikd Subscribers: thomie, carter GHC Trac Issues: #7836 Differential Revision: https://phabricator.haskell.org/D4567 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:08:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:08:00 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.02f1f0e329e6516c96eeeba3f67482a8@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: This is now a proper error. Phyx, should this ticket remain open or is this as fixed as this will be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:08:04 -0000 Subject: [GHC] #15032: GHCi panics when attempting to load archives In-Reply-To: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> References: <052.290df7e4af81ac6e48b622d87c157560@haskell.org> Message-ID: <067.43b6ca9622c2ccc0741845aff6dc358b@haskell.org> #15032: GHCi panics when attempting to load archives ----------------------------------+-------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.2-rc1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #9438 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"7613a812888424b49cb334a4e63bd7280adf2774/ghc" 7613a812/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7613a812888424b49cb334a4e63bd7280adf2774" Fix #9438 by converting a panic to an error message Previously, GHC was quite eager to panic whenever it was fed an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an explicit error message instead, so this patch accomplishes just that. Test Plan: make test TEST=T14708 Reviewers: Phyx, hvr, bgamari Reviewed By: Phyx Subscribers: thomie, carter GHC Trac Issues: #9438, #14708, #15032 Differential Revision: https://phabricator.haskell.org/D4589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:08:04 -0000 Subject: [GHC] #14708: GHC panics when linking with an archive and using an annotation In-Reply-To: <046.3ba93269311e390d484d95c8a405c373@haskell.org> References: <046.3ba93269311e390d484d95c8a405c373@haskell.org> Message-ID: <061.2e875f3c1d248e4f4374264ce29da694@haskell.org> #14708: GHC panics when linking with an archive and using an annotation -------------------------------------+------------------------------------- Reporter: tchajed | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #9438 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7613a812888424b49cb334a4e63bd7280adf2774/ghc" 7613a812/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7613a812888424b49cb334a4e63bd7280adf2774" Fix #9438 by converting a panic to an error message Previously, GHC was quite eager to panic whenever it was fed an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an explicit error message instead, so this patch accomplishes just that. Test Plan: make test TEST=T14708 Reviewers: Phyx, hvr, bgamari Reviewed By: Phyx Subscribers: thomie, carter GHC Trac Issues: #9438, #14708, #15032 Differential Revision: https://phabricator.haskell.org/D4589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:08:04 -0000 Subject: [GHC] #9438: panic: loading archives not supported In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.3e728397a1e8f721044257a49697fe67@haskell.org> #9438: panic: loading archives not supported -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7613a812888424b49cb334a4e63bd7280adf2774/ghc" 7613a812/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7613a812888424b49cb334a4e63bd7280adf2774" Fix #9438 by converting a panic to an error message Previously, GHC was quite eager to panic whenever it was fed an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an explicit error message instead, so this patch accomplishes just that. Test Plan: make test TEST=T14708 Reviewers: Phyx, hvr, bgamari Reviewed By: Phyx Subscribers: thomie, carter GHC Trac Issues: #9438, #14708, #15032 Differential Revision: https://phabricator.haskell.org/D4589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:09:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:09:15 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.f3549325f2b6e4bad6237a7719b1fe9d@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): The latest behavior using 8.5.20180413 on my Mac is that if I type `3 _ 4` or `3 _` GHCI now hangs, which I do not consider an improvement over the panic. I have to type `^C` to break. If I type something like `_` or `_ 3` I get a `Found hole` message as expected. Reopening, but if it makes more sense to file a new bug instead I can do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:10:27 -0000 Subject: [GHC] #14969: panic on incorrect syntax In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.a8f64d65fa67cae78e32016b40c947b6@haskell.org> #14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:11:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:11:27 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.b8d9fa52e48996732f7999019be6ca99@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Azel Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode, | 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 Azel): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:16:11 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.90e229ed6d25ee377ae350b4e154db5c@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:20:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:20:04 -0000 Subject: [GHC] #9438: Dynamic GHCi doesn't support static libraries (was: panic: loading archives not supported) In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.af8ef703990c18e1002d715363256b41@haskell.org> #9438: Dynamic GHCi doesn't support static libraries -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * type: bug => feature request Comment: Indeed, I've converted this to a feature request per https://phabricator.haskell.org/D4589#126967. (Alas, that means the commit message in comment:10 is misleading, since that commit didn't actually fix this ticket. Oh well.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:22:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:22:18 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant (was: panic on incorrect syntax) In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.f59488bfd3aaa79e85bf54302e1c2b68@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * failure: None/Unknown => Compile-time performance bug Comment: Note that it doesn't loop infinitely, but rather takes a very long time to compute: {{{ $ time ghc/inplace/bin/ghc-stage2 -XFlexibleContexts -e "3 _ 4" :0:1: error: • Could not deduce (Num t1) from the context: (Num t, Num (t2 -> t -> t3)) bound by the inferred type for ‘it’: forall t t2 t3. (Num t, Num (t2 -> t -> t3)) => t3 at :0:1-5 The type variable ‘t1’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall t1 t2 t3. (Num t1, Num (t2 -> t1 -> t3)) => t3 real 0m32.219s user 0m32.176s sys 0m0.084s }}} In other words, this is the same problem observed in https://ghc.haskell.org/trac/ghc/ticket/10946#comment:9. This is good home for this particular bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 16:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 16:23:15 -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.9946a6e3e20bdac44748756085b4a0dd@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: 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 RyanGlScott): * related: => #14969 Comment: #14969 is the new home for the performance issue brought up in comment:9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 17:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 17:00:58 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.29f929d13941c58512e92fb4ce62541d@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: llvm Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 12915 14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Rolled back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 17:11:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 17:11:22 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.22e6d2576696dcc33292c876461ea2d0@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ce27c7d5fe3c335dcc354b70fdfc17831a6848f6/ghc" ce27c7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce27c7d5fe3c335dcc354b70fdfc17831a6848f6" Correct FixIOException's @since annotation retroactively Summary: In D4113, a `FixIOException` data type was added with a `@since TODO` annotation, but it seems that `TODO` made it out into `base-4.11` itself. I've (retroactively) fixed this and added an entry to the `base-4.11` entry in the `changelog`. Test Plan: Read it Reviewers: dfeuer, hvr, bgamari Reviewed By: dfeuer Subscribers: thomie, carter GHC Trac Issues: #14356, #15025 Differential Revision: https://phabricator.haskell.org/D4578 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 17:11:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 17:11:22 -0000 Subject: [GHC] #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO In-Reply-To: <046.213052b44c9d3401325e49943e41332d@haskell.org> References: <046.213052b44c9d3401325e49943e41332d@haskell.org> Message-ID: <061.528e9579481450b17f21e454a19e29dd@haskell.org> #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ce27c7d5fe3c335dcc354b70fdfc17831a6848f6/ghc" ce27c7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce27c7d5fe3c335dcc354b70fdfc17831a6848f6" Correct FixIOException's @since annotation retroactively Summary: In D4113, a `FixIOException` data type was added with a `@since TODO` annotation, but it seems that `TODO` made it out into `base-4.11` itself. I've (retroactively) fixed this and added an entry to the `base-4.11` entry in the `changelog`. Test Plan: Read it Reviewers: dfeuer, hvr, bgamari Reviewed By: dfeuer Subscribers: thomie, carter GHC Trac Issues: #14356, #15025 Differential Revision: https://phabricator.haskell.org/D4578 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 17:12:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 17:12:36 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.01aca0def1d655b2fabdac8889822584@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Both c4814ab6b8d756ae0e32c9a9f44e4888c4e24763 and ce27c7d5fe3c335dcc354b70fdfc17831a6848f6 ought to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 18:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 18:17:23 -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.842672e29c68bf304c119cc0e5d1e415@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 Operating System: 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:"00b8ecb78624511a045120673b01fafe5794ecdc/ghc" 00b8ecb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00b8ecb78624511a045120673b01fafe5794ecdc" Declare `catchRetry#` lazy in its first argument As per the results on item 1 in T14998, declaring `catchRetry#` lazy in its first argument opens the possibility to remove `ExnStr` complexity from strictness demands at virtually no regressions in NoFib. This brings `catchRetry#` in line with other primops from the `catch*` family. Reviewers: bgamari, simonpj, nomeata Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14998, #11222 Differential Revision: https://phabricator.haskell.org/D4573 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 18:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 18:17:23 -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.1939140c1d86180ff32bed8fe98bf156@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"00b8ecb78624511a045120673b01fafe5794ecdc/ghc" 00b8ecb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00b8ecb78624511a045120673b01fafe5794ecdc" Declare `catchRetry#` lazy in its first argument As per the results on item 1 in T14998, declaring `catchRetry#` lazy in its first argument opens the possibility to remove `ExnStr` complexity from strictness demands at virtually no regressions in NoFib. This brings `catchRetry#` in line with other primops from the `catch*` family. Reviewers: bgamari, simonpj, nomeata Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14998, #11222 Differential Revision: https://phabricator.haskell.org/D4573 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 18:17:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 18:17:52 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.e318979479f17875c7b0c9575dfb441c@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | Phab:D4486 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9e89092d4ee1effd558757361fb62b83697f8f42/ghc" 9e89092d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e89092d4ee1effd558757361fb62b83697f8f42" Omit ways depending on rts flags for #12870 related tests. Some of these tests instruct the RTS to ignore all RTS flags being passed. While this is intended it causes test failures for some ways like profiling which depend on passing RTS flags. So we skip these ways. Test Plan: testsuite/tests/rts/flags$ make slow Reviewers: bgamari, simonmar, alpmestan Reviewed By: alpmestan Subscribers: alpmestan, thomie, carter GHC Trac Issues: #12870 Differential Revision: https://phabricator.haskell.org/D4585 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 18:21:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 18:21:45 -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.ea9a9dc327aa3206f90ea1fbdbfd5114@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 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 bgamari): Can you offer any information about the nature of your application? Does it use concurrency? STM? Make heavy use of exceptions? Any additional information would be helpful. Of course, a core dump would also be extremely helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 18:24:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 18:24:22 -0000 Subject: [GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent In-Reply-To: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> References: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> Message-ID: <059.f88b87e5cf60374ee7b00436229e2dda@haskell.org> #14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.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: Jaffacake (added) * priority: normal => high * milestone: => 8.6.1 Comment: This sounds like a bug to me. I too would expect `load` to be idempotent. CCing Jaffacake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 21:09:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 21:09:09 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.52c773da90ffbbd925b186150a873bce@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): I've reworked the substitution suggestions a lot over the past few weeks, and I've updated the sorting to be based on sizes of matches rather than by subsumption (though sorting by subsumption is still available via a flag). I hope to submit the patch this weekend, after I've updated the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 22:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 22:07:30 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.db752ce39c807394840f8a8ec2a54dd3@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fea04defa64871caab6339ff3fc5511a272f37c7/ghc" fea04de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fea04defa64871caab6339ff3fc5511a272f37c7" Enhanced constant folding Until now GHC only supported basic constant folding (lit op lit, expr op 0, etc.). This patch uses laws of +/-/* (associativity, commutativity, distributivity) to support some constant folding into nested expressions. Examples of new transformations: - simple nesting: (10 + x) + 10 becomes 20 + x - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t))) - distribution: (5 + x) * 6 becomes 30 + 6*x - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x) - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie GHC Trac Issues: #9136 Differential Revision: https://phabricator.haskell.org/D2858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 13 22:46:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Apr 2018 22:46:45 -0000 Subject: [GHC] #15028: Deprecate and Remove Data.Semigroup.Option/First/Last (was: Deprecate and Remove Data.Semigroup.Option) In-Reply-To: <049.03897d3322661841e0dfff5e5126841a@haskell.org> References: <049.03897d3322661841e0dfff5e5126841a@haskell.org> Message-ID: <064.2ca8c7da22879798dd4fb0aa0d9d0724@haskell.org> #15028: Deprecate and Remove Data.Semigroup.Option/First/Last -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: base 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 andrewthad): * cc: ekmett (added) * version: 8.2.2 => 8.4.1 * milestone: 8.6.1 => 8.8.1 Old description: > Since the Semigroup-Monoid Proposal has landed, the data type `Option` > from `Data.Semigroup` is now obsolete. I propose that it be marked > deprecated in GHC 8.6 and removed in GHC 8.10. New description: Since the Semigroup-Monoid Proposal has landed, the data type `Option` from `Data.Semigroup` is now obsolete. I propose that it be marked deprecated in GHC 8.6 and removed in GHC 8.10. --- EDIT --- A proposal on the libraries mailing list for the removal of First and Last from Data.Monoid met with a positive response: https://mail.haskell.org/pipermail/libraries/2018-April/028712.html I figured it would be best to track all of these on the same ticket. In a response to the aforementioned mailing list thread, Edward Kmett suggested that the timing for deprecation and removal be GHC 8.8 and GHC 8.10 respectively. This will make it possible to adhere to the three-release policy with ease. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:34:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:34:24 -0000 Subject: [GHC] #10367: "ghc: panic! (the 'impossible' happened)" In-Reply-To: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> References: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> Message-ID: <061.2d41c63c1338cb15ccf6c9b2b6255c3f@haskell.org> #10367: "ghc: panic! (the 'impossible' happened)" ----------------------------------+---------------------------------------- Reporter: bgwines | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: panic 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 George): Is this still reproducible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:36:41 -0000 Subject: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation In-Reply-To: <048.bcd71639490682a6b2cce6627a019c28@haskell.org> References: <048.bcd71639490682a6b2cce6627a019c28@haskell.org> Message-ID: <063.ad6b75120e78238cc53f3207c2032839@haskell.org> #4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.12.3 Resolution: | Keywords: MVar Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by George): I can't reproduce this on 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:41:32 -0000 Subject: [GHC] #9307: LLVM vs NCG: floating point numbers close to zero have different sign In-Reply-To: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> References: <042.6d7e0c37dce6aa97cc1ca70e5fb349be@haskell.org> Message-ID: <057.4d65394d57494bba765cdc3a0d30e9e2@haskell.org> #9307: LLVM vs NCG: floating point numbers close to zero have different sign -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.8.3 Resolution: | Keywords: wave4main Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Is this reproducible on 8.4.1 with llvm 5.0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:48:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:48:35 -0000 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> References: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> Message-ID: <065.5952039b9c4ec154d67fc0c2af7dabc4@haskell.org> #2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => closed * resolution: => fixed Comment: It's been 9 years since the bug was reported . Apple released Mac OS X v10.6 "Snow Leopard" on August 28, 2009 as Intel-only, removing support for the PowerPC architecture. It is also the last Mac OS X version that support PowerPC based applications. Can we close this as wontfix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:50:09 -0000 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> References: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> Message-ID: <065.e92ff78f7cd3711bda123f3249e94890@haskell.org> #2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: fixed => Comment: Didn't mean to close it, asking if we can close it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:53:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:53:36 -0000 Subject: [GHC] #15033: ScopedTypeVariable and RankNTypes don't scope throughout function body Message-ID: <050.ae8f76f6465ef0325fabec86dc79ed37@haskell.org> #15033: ScopedTypeVariable and RankNTypes don't scope throughout function body -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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'm writing a DSL that uses `TypeApplications`, and I noticed the following weird behavior with `ScopedTypeVariables` and `AllowAmbiguousTypes`. You can define a function that takes the `TypeApplication` after a parameter: {{{#!hs lol :: String -> forall a. IO () lol str = putStrLn str main = lol "hello" @Int }}} This works! Unfortunately, it is impossible to *refer* to that `a` type variable in the body of the function. It is as though `ScopedTypeVariables` were not turned on. A reproduction (tested on 8.2.2 and 8.4.1): {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Typeable import Data.Proxy no :: String -> forall x. Typeable x => IO () no _ = print (typeRep (Proxy :: Proxy x)) yes :: forall x. Typeable x => String -> IO () yes _ = print (typeRep (Proxy :: Proxy x)) }}} `no` fails to compile, saying that `x` type variable is not in scope. `yes` works just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 01:56:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 01:56:42 -0000 Subject: [GHC] #10631: Report of GHC Panic loading temp shared object (was: Report of GHC Panic) In-Reply-To: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> References: <048.0d7915ea1be06d70aee5e73f020551d8@haskell.org> Message-ID: <063.deb3283db1c1d0d4eeee600b3b31a93d@haskell.org> #10631: Report of GHC Panic loading temp shared object -------------------------------------+------------------------------------- Reporter: seewalker | Owner: (none) Type: bug | Status: infoneeded Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Keywords: "flat Resolution: | namespace" Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => infoneeded * keywords: => "flat namespace" Comment: Can you tell us how to reproduce this? I think there were errors fixed wrt the Mac flat namespace. So it is possible that this was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 05:22:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 05:22:18 -0000 Subject: [GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be Message-ID: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> #15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE RecursiveDo #-} module Main where a :: String a = "hello" test :: IO () test = mdo putStrLn a let a = 3 :: Int print a }}} With both GHC 8.2.2 and GHC 8.4.1, it fails with the following error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:10:5: error: • Couldn't match type ‘Int’ with ‘[Char]’ Expected type: String Actual type: Int • In a stmt of an 'mdo' block: rec putStrLn a let a = (3 :: Int) In the expression: mdo rec putStrLn a let a = ... print a In an equation for ‘test’: test = mdo rec putStrLn a let ... print a | 10 | putStrLn a | ^^^^^^^^^^ }}} I would expect it to succeed, with `a` shadowing the top-level definition. The desugared output in the error message tells us what is wrong: it is grouping `putStrLn a; let a = ...` together! If I alter the program to be: {{{#!hs a :: String a = "hello" test :: IO () test = do rec putStrLn a let a = 3 :: Int print a }}} Then it does the Right Thing. Looking at the [https://prime.haskell.org/wiki/RecursiveDo Haskell Prime wiki entry for Recursive Do], this seems to be the relevant bit: > That is, a variable used before it is bound is treated as recursively defined, while in a Haskell 98 do-statement it would be treated as shadowed. I have a more complicated reproduction involving `ST` types and complaints of skolem type variables escaping scope: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE RecursiveDo #-} module Main where import Control.Monad.ST theThing :: ST s () theThing = pure () weirdlyLocal :: ST s () weirdlyLocal = theThing runSTIO :: (forall s. ST s a) -> IO a runSTIO x = pure (runST x) thisWorks :: IO () thisWorks = mdo let weirdlyLocal = theThing runSTIO weirdlyLocal runSTIO weirdlyLocal thisBreaks :: IO () thisBreaks = mdo runSTIO weirdlyLocal let weirdlyLocal = theThing runSTIO weirdlyLocal thisIsFine :: IO () thisIsFine = mdo runSTIO weirdlyLocal let asdf = theThing runSTIO asdf }}} This demonstrates an even more bizarre behavior! If I move the `let` up to the top, then it no longer gets included in a `rec`, and it compiles fine. If I move it under the first statement, then I get this error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:25:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:25:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In a stmt of an 'mdo' block: rec runSTIO weirdlyLocal let weirdlyLocal = theThing • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 25 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ /home/matt/Projects/ghc-repro/src/Main.hs:27:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:27:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In the expression: mdo rec runSTIO weirdlyLocal let weirdlyLocal = ... runSTIO weirdlyLocal • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 27 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 07:12:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 07:12:28 -0000 Subject: [GHC] #13450: Better parse error for empy character literal In-Reply-To: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> References: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> Message-ID: <065.4592b2cdd248816ed4f32adb3f85937d@haskell.org> #13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T13450 | parser/should_fail/T13450TH Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * testcase: => parser/should_fail/T13450 parser/should_fail/T13450TH * differential: => Phab:D4594 * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 07:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 07:34:55 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.8588d2acc2ea91c33485adaf9365325a@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Azel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4593 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: new => patch * differential: => Phab:D4593 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 08:55:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 08:55:27 -0000 Subject: [GHC] #15035: Panic when using StaticPointers with typed holes Message-ID: <046.defebaf619831fea68b595f22fb54b63@haskell.org> #15035: Panic when using StaticPointers with typed holes -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Adding a type hole when there is a type variable in `StaticPtr` throws a GHC panic: {{{#!hs {-# LANGUAGE StaticPointers #-} module Foo where import Data.Typeable import GHC.StaticPtr foo :: Typeable a => StaticPtr a foo = static _ }}} {{{ [1 of 1] Compiling Foo ( test.hs, test.o ) test.hs:9:14: error:ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): No skolem info: [a_aD2[sk:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2945:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panics on both GHC 8.2.2 and 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 10:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 10:38:56 -0000 Subject: [GHC] #10920: ghci can't load local Prelude module In-Reply-To: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> References: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> Message-ID: <059.9361a6533fbae027ae4e8cda27524e2f@haskell.org> #10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.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 lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 11:30:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 11:30:03 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.0134ebc9557c6b63d705dccda29721af@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by Azel): I'm willing to have a go at this issue, is anyone already working on it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 11:30:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 11:30:13 -0000 Subject: [GHC] #2207: Load the interface details for GHC.* even without -O In-Reply-To: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> References: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> Message-ID: <061.07b8550a2e665909d41f11b40712b918@haskell.org> #2207: Load the interface details for GHC.* even without -O -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): I'm willing to have a go at this issue, is anyone already working on it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 12:26:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 12:26:23 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.6e9b53594a7592403c6d69329625f7f1@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by Phyx-): No it's free for the taking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 12:52:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 12:52:27 -0000 Subject: [GHC] #15036: STG Linter dies when linting primitive Message-ID: <049.5d929eed8a18acc7dc4ad5d96bdc4436@haskell.org> #15036: STG Linter dies when linting primitive -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Steps to reproduce: - Check out the master branch of primitive. Commit hash is currently 6b49e83fef0126ac09db7acf47f16df43ebce61b. - `cabal new-build -w ghc-8.4.1 --ghc-options -dstg-lint` - The impossible happened Ben, I saw that you had been fixing the stg linter so I'm CCing you in case this is related to your work on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 13:40:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 13:40:55 -0000 Subject: [GHC] #15033: ScopedTypeVariable and RankNTypes don't scope throughout function body In-Reply-To: <050.ae8f76f6465ef0325fabec86dc79ed37@haskell.org> References: <050.ae8f76f6465ef0325fabec86dc79ed37@haskell.org> Message-ID: <065.20c1daa837836bf681cf0b8b2cdb2803@haskell.org> #15033: ScopedTypeVariable and RankNTypes don't scope throughout function body -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 Comment: This is by design. If you want to make a type variable scope over the body of a function, it must be quantified by the outermost, syntactically visible `forall` of the type signature. Per the [http://git.haskell.org/ghc.git/blob/fea04defa64871caab6339ff3fc5511a272f37c7:/docs/users_guide/glasgow_exts.rst#l9896 users' guide]: > The type variable is quantified by the single, syntactically visible, outermost `forall` of the type signature. For example, GHC will reject all of the following examples: > > {{{#!hs > f1 :: forall a. forall b. a -> [b] -> [b] > f1 _ (x:xs) = xs ++ [ x :: b ] > > f2 :: forall a. a -> forall b. [b] -> [b] > f2 _ (x:xs) = xs ++ [ x :: b ] > > type Foo = forall b. [b] -> [b] > > f3 :: Foo > f3 (x:xs) = xs ++ [ x :: b ] > }}} > > In `f1` and `f2`, the type variable `b` is not quantified by the outermost `forall`, so it is not in scope over the bodies of the functions. Neither is `b` in scope over the body of `f3`, as the `forall` is tucked underneath the `Foo` type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 13:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 13:46:52 -0000 Subject: [GHC] #15035: Panic when using StaticPointers with typed holes In-Reply-To: <046.defebaf619831fea68b595f22fb54b63@haskell.org> References: <046.defebaf619831fea68b595f22fb54b63@haskell.org> Message-ID: <061.98285a556088ff9ab7bbd784cf151463@haskell.org> #15035: Panic when using StaticPointers with typed holes -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: | StaticPointers, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13499 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => StaticPointers, TypedHoles * status: new => closed * resolution: => duplicate * related: => #13499 Comment: Closing as a duplicate of #13499. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 13:47:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 13:47:15 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.06ffd92af2a289d7ecbdb94b7600f52d@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, TypedHoles Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: StaticPointers, hole, skolem, panic => StaticPointers, TypedHoles * related: => #15035 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 13:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 13:55:24 -0000 Subject: [GHC] #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error Message-ID: <050.98285fdaf8bf325881a177fbc13f2378@haskell.org> #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Keywords: TypedHoles | 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: -------------------------------------+------------------------------------- Originally reported in https://ghc.haskell.org/trac/ghc/ticket/14996#comment:2. You need GHC HEAD (i.e., more recent than GHC 8.4.1) to trigger this: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> 1 1 λ> 1 1 λ> _ :1:1: error: GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} And yes, running `1` //twice// seems to be critical to triggering this bug, for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 13:55:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 13:55:45 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.5713333cc6278c59c20eddf64f0986be@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14969, #15037 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #14969, #15037 Comment: Oops, I accidentally converted #14969 to be about the performance issue before seeing this ticket. I think I'll keep #14969 the way it is and close this in favor of a new ticket, #15037, about the issue in comment:2 And yes, to reiterate what monoidal said, you do need to run `1` //twice// in GHCi before running `_`, or else it won't be triggered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:07:21 -0000 Subject: [GHC] #15036: STG Linter dies when linting primitive In-Reply-To: <049.5d929eed8a18acc7dc4ad5d96bdc4436@haskell.org> References: <049.5d929eed8a18acc7dc4ad5d96bdc4436@haskell.org> Message-ID: <064.1bd67902787401a0dddbb3d25c9c7092@haskell.org> #15036: STG Linter dies when linting primitive -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14787 Comment: This can be reduced down to: {{{#!hs module Bug where foreign import ccall unsafe "wat" wat :: IO () }}} {{{ $ ghc Bug.hs -dstg-lint -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Unarise *** : warning: [in body of lambda with binders void_0E :: Void#] In some algebraic case alternative, constructor is not a constructor of scrutinee type: (# State# RealWorld #) (##) *** Offending Program *** $trModule1_r1b1 :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] = "main"#; $trModule2_r1bm :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE TrNameS! [$trModule1_r1b1]; $trModule3_r1bn :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] = "Bug"#; $trModule4_r1bo :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE TrNameS! [$trModule3_r1bn]; $trModule :: Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Module! [$trModule2_r1bm $trModule4_r1bo]; wat1_r1bp :: State# RealWorld -> (# State# RealWorld, () #) [GblId, Arity=1, Caf=NoCafRefs, Unf=OtherCon []] = sat-only [] \r [void_0E] case __pkg_ccall main [void#] of { (##) -> Unit# [()]; }; wat :: IO () [GblId, Arity=1, Caf=NoCafRefs, Unf=OtherCon []] = [] \r [void_0E] wat1_r1bp void#; *** End of Offense *** Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/stgSyn/StgLint.hs:68:19 in ghc:StgLint }}} However, osa1 fixed this in #14787—and indeed, `primitive` builds on GHC HEAD with `-dstg-lint`, both in version 0.6.3.0 and upstream—so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:13:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:13:54 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.1c7d70dff6fd4aef39c6c33ecba32760@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well I'll be danged—it looks like this no longer panics on GHC HEAD! {{{ $ ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:21:18: error: • Couldn't match type ‘k0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for: elimWeirdList :: forall a1 (wl :: WeirdList a1) (p :: forall x. x -> WeirdList x -> *). Sing wl -> (forall y. p k0 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k1 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl at Bug.hs:(21,18)-(28,23) Expected type: Sing wl -> (forall y. p k1 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k0 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl Actual type: Sing wl -> (forall y. p k1 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k0 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl • In the ambiguity check for ‘elimWeirdList’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 21 | elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Bug.hs:34:8: error: • Cannot apply expression of type ‘Sing wl -> (forall y. p k0 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k1 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl’ to a visible type argument ‘(WeirdList z)’ • In the sixth argument of ‘pWeirdCons’, namely ‘(elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons)’ In the expression: pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) In an equation for ‘elimWeirdList’: elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) | 34 | (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'll confirm which commit caused this and add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:20:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:20:57 -0000 Subject: [GHC] #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error In-Reply-To: <050.98285fdaf8bf325881a177fbc13f2378@haskell.org> References: <050.98285fdaf8bf325881a177fbc13f2378@haskell.org> Message-ID: <065.72f9f85cd15a8bea454b05b0a0a06100@haskell.org> #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => closed * resolution: => duplicate * related: => #15007 Comment: Oh wait, Ryan, I have opened the ticket:15007 several days ago for this bug (and possible solution). I'm going to close this ticket as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:22:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:22:21 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.7e7b19cdaa268867a0a5cedc0493f731@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypedHoles Old description: > In ticket:14052, we reverted Phab:D2447, then ticket:11547 exists in HEAD > again. In ticket:14052#comment:25 and ticket:14052#comment:10, we decide > that shadowed variables shouldn't be keep at all. This ticket is created > to track the idea. > > The same error of ticket:11547 was also reported in > ticket:14996#comment:2, > > > {{{#!hs > > $ inplace/bin/ghc-stage2 --interactive > > GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help > > Prelude> 1 > > 1 > > Prelude> 1 > > 1 > > Prelude> _ > > > > :1:1: error: > > GHC internal error: ‘Ghci1.it’ is not in scope during type > > checking, but it passed the renamer > > tcl_env of environment: [] > >}}} > > > > (giving "1" twice is needed to reproduce the error) > > NB: input "1" twice to create shadowed context is necessary to reproduce > this bug. New description: In ticket:14052, we reverted Phab:D2447, then ticket:11547 exists in HEAD again. In ticket:14052#comment:25 and ticket:14052#comment:10, we decide that shadowed variables shouldn't be keep at all. This ticket is created to track the idea. The same error of ticket:11547 was also reported in ticket:14996#comment:2, > {{{ > $ inplace/bin/ghc-stage2 --interactive > GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help > Prelude> 1 > 1 > Prelude> 1 > 1 > Prelude> _ > > :1:1: error: > GHC internal error: ‘Ghci1.it’ is not in scope during type > checking, but it passed the renamer > tcl_env of environment: [] >}}} > > (giving "1" twice is needed to reproduce the error) NB: input "1" twice to create shadowed context is necessary to reproduce this bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:22:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:22:43 -0000 Subject: [GHC] #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error In-Reply-To: <050.98285fdaf8bf325881a177fbc13f2378@haskell.org> References: <050.98285fdaf8bf325881a177fbc13f2378@haskell.org> Message-ID: <065.51345fc0b2d98ab84852742929428660@haskell.org> #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oops, I somehow missed //that// ticket as well. Sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:34:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:34:21 -0000 Subject: [GHC] #14996: Typed holes are very slow In-Reply-To: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> References: <046.bbc78e2849821665a6c53e1d69d859b0@haskell.org> Message-ID: <061.5f84fb20e243e1ecac50bf45155081cc@haskell.org> #14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14969, #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14969, #15037 => #14969, #15007 Comment: Sorry, #15007, not #15037. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 14:50:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 14:50:52 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.c66f938440e2154aab5b8b13e4e44155@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Never mind, I'm an idiot. I was looking at the original program, not the program in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 15:11:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 15:11:42 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.1116f384251e788856388d84f98b9958@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, TypedHoles Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I have noticed another interesting behavior, when compile the program in description with {{{ inplace/bin/ghc-stage2.exe --make T.hs }}} The ghc-stage2.exe panics within 5 seconds. However, if I dump the tc trace, {{{ inplace/bin/ghc-stage2.exe --make T.hs -ddump-tc-trace }}} The ghc-stage2.exe runs into infinite loop and continues to produce a huge dump file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 18:57:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 18:57:03 -0000 Subject: [GHC] #14947: internal error: Invalid object *c in push() In-Reply-To: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> References: <045.1b0222011edccbe034bce0a38cb61ba9@haskell.org> Message-ID: <060.87e78d6bc4940bced428c1df33162f7a@haskell.org> #14947: internal error: Invalid object *c in push() -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 0ec1bd64b3317febe8c018041f538f1c83135e6c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 18:58:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 18:58:01 -0000 Subject: [GHC] #15025: Lingering @since TODO Haddock annotations In-Reply-To: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> References: <050.e75e63eac55e47562291e6ed1f5ed01e@haskell.org> Message-ID: <065.5cf6d70902a2f9b12392c6d90d85e855@haskell.org> #15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | 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:D4578, Wiki Page: | Phab:D4586 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Both merged to `ghc-8.4`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 18:59:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 18:59:54 -0000 Subject: [GHC] #15002: Panic: collectNBinders In-Reply-To: <047.4bed8603d13edea0830249b5fa334075@haskell.org> References: <047.4bed8603d13edea0830249b5fa334075@haskell.org> Message-ID: <062.577115468dbc01c879db97c5069cdc10@haskell.org> #15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: nomeata Type: bug | Status: closed Priority: highest | Milestone: 8.4.2 Component: Profiling | Version: 8.4.1 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:D4572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.4` for 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 20:13:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 20:13:04 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.4f397241a6c5d37cd216cb621f6a2eaf@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by br1): @dfeuer Here's the paper https://www.fing.edu.uy/~mviera/papers/pepm13.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 21:50:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 21:50:06 -0000 Subject: [GHC] #14936: GHC 8.4 performance regressions when using newtypes In-Reply-To: <046.51c083465a95f77099b97377aa2723e3@haskell.org> References: <046.51c083465a95f77099b97377aa2723e3@haskell.org> Message-ID: <061.77958dd7c1d8eda9f974c1f6963aaa67@haskell.org> #14936: GHC 8.4 performance regressions when using newtypes -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/should_run/T14936 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: I was on the fence about this one but ended up merging it since it looks fairly low-risk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 14 21:50:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Apr 2018 21:50:45 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNTAwNTogR0hDIGZhaWxzIHdpdGgg4oCcU3Rn?= =?utf-8?q?CmmEnv=3A_variable_not_found=E2=80=9D_when_trying_to_c?= =?utf-8?q?ompile_order-maintenance-0=2E2=2E1=2E0?= In-Reply-To: <046.af15ef1093894b502a607404865aa94e@haskell.org> References: <046.af15ef1093894b502a607404865aa94e@haskell.org> Message-ID: <061.718defee0859eae141befe5303a1891b@haskell.org> #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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:D4582 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.4` as 2f5b97c37dbc9708e7a33b4e36f66a12b32ee09f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 15 23:41:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Apr 2018 23:41:26 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.cc6b1650416ea9e856b77d130fba3597@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: new => patch Comment: A fix for this is included in https://phabricator.haskell.org/D4444, where we change the default sorting algorithm to one based on comparing sizes of types rather than subsumption, which is much faster and gives comparable results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 02:24:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 02:24:42 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) Message-ID: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been encountering corruption of memory in a library of mine that uses some of GHC's more recent features (levity polymorphism and unboxed sums). The library is `packed`, and it's source code can be found on my github. But, more relevant to this issue is the minimal reproducible example I've put together here: https://github.com/andrewthad/corrupted-memory-example It's still a bit larger than I'd like it to be, and if no one has any insights into this, I can keep whittling it down to make it more minimal. Here's how to run it: {{{ git clone https://github.com/andrewthad/corrupted-memory-example cd corrupted-memory-example cabal new-build --enable-tests test ./dist-newstyle/build/corrupted-memory-example-0.1/build/test/test }}} This consistently crashes with: {{{ test: internal error: evacuate(static): strange closure type 16648 (GHC version 8.4.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Additional information: This issue can be reproduced using GHC 8.2.2, GHC 8.4.1, and GHC HEAD. This project cannot be built with GHC 8.0.2 and earlier since it uses unboxed sums. Building this project with either `stack` or `cabal new-build` and then running the test causes the same crash. However, building it with plain old GHC and then running it does not. This is really weird, since there aren't any GHC options in the cabal file that should affect this. In the original library, I have a bunch of tests that use the parsers `byte` and `any` in a variety of situations, and none of them every trigger this crash except for the ones where I stick a `Parser` inside of a `Trie`. This project does a lot of manual passing of state tokens, but I believe all of these uses to be correct (mostly because of the extensive tests in the original repo, but I've also spent a lot of time just looking at the code to figure out if this was something on my end). Let me know if the example is too big. I can spend some more time shrinking it further, but I wanted to go ahead and get it up here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 02:32:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 02:32:29 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.feefd24bf91cce9659019c086e81ded5@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Azel Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by Azel): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 02:37:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 02:37:56 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature Message-ID: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following GHCi session: {{{ $ ghci GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import Data.Type.Coercion λ> foo :: _ => Coercion a b; foo = Coercion :2:8: error: • Found type wildcard ‘_’ standing for ‘Coercible a b :: TYPE ('GHC.Types.TupleRep '[])’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: Coercible a b => Coercion a b at :2:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b λ> :set -fprint-explicit-kinds λ> foo :: _ => Coercion a b; foo = Coercion :4:8: error: • Found type wildcard ‘_’ standing for ‘(a :: *) ~~ (b :: *) :: TYPE ('GHC.Types.TupleRep ('[] GHC.Types.RuntimeRep))’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: ((a :: *) ~~ (b :: *)) => Coercion * a b at :4:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b }}} There are two things quite strange about this: 1. In both error messages, GHC claims that `Coercible a b`/`a ~~ b` has kind `TYPE (TupleRep '[])`. This is wrong, and should be `Coercible`. 2. For some reason, enabling `-fprint-explicit-kinds` causes the inferred constraint to be `(~~)` instead of `Coercible`, which is just plain wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 05:54:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 05:54:41 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.500c80386b8c5a3c93c9d30ff0cfcdbf@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 07:34:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 07:34:36 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD Message-ID: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Build System | Version: 8.4.1 Keywords: dtrace | Operating System: FreeBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.4.1 enables DTrace probes on FreeBSD. This currently causes issues with the using such compilers as a bootstrap compiler for building GHC itself due to the way linking of the RTS is handled. I didn't encounter any issues regarding daily use on FreeBSD but suspect it might cause problems with user defined hooks. Current workaround is to build a version of GHC with DTrace disabled and use that as a bootstrap compiler. A patch has been merged into HEAD. I've already tested it in combination with 8.4.2-rc1 and it worked fine. https://phabricator.haskell.org/rGHC4b831c27926d643b0b6fad82c1e946d05cde8645 I have an idea on how to fix this but haven't had the time to put that plan into action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:20:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:20:59 -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.f8f04b81bd5204667d6bd0410e34af45@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 Operating System: 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): > Declare `catchRetry#` lazy in its first argument Great. So now we can dump all the `ThrowsExn` machinery! sgraf, are you up for doing that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:21:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:21:38 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.dd29cfffa9ec8e1711bbc41d359ab868@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: 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 Tritlo): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:26:59 -0000 Subject: [GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be In-Reply-To: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> References: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> Message-ID: <065.1b0e2b57532c5c6b006685e2ea363a8e@haskell.org> #15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Looking at the ​Haskell Prime wiki entry for Recursive Do, this seems to be the relevant bit: That is, a variable used before it is bound is treated as recursively defined, while in a Haskell 98 do-statement it would be treated as shadowed. So it looks as if GHC is following the specification. Are you proposing a different specification? And if so, what is it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:36:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:36:31 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.32b536890fe1caa7e0b4048ced7fe249@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for making a repro case. Yes, shrinking it is incredibly valuable. Did you compile everything with `-dcore-lint`? Always worth doing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:36:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:36:57 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.b77862ae956b97b0841b34eab5c44db9@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:50:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:50:12 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.aa7a98bdbd101a7b2c9bca17c5a2124a@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 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:D4444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 08:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 08:51:09 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.cf0eb9fd5492856973df4b943e5e6e86@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:03:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:03:51 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.6c38b369c7209961ff44a74148288ff7@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * owner: sighingnow => simonmar Comment: Simon, might you take a look? GHC should never crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:09:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:09:16 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.bafd512fccd4e7697f32c435c7c36131@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Indeed it's not a crash, it's just an ordinary error message with description "GHC internal error:". The error is reported in `noFound` method in TcEnv.hs. {{{#!hs _ -> failWithTc $ vcat[text "GHC internal error:" <+> quotes (ppr name) <+> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:10:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:10:58 -0000 Subject: [GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2` In-Reply-To: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> References: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> Message-ID: <064.c8017ddc8d43071e7f465c6f13dbabf8@haskell.org> #15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Of `tcExtendTyVarEnvByName`? The comments on the definition could make it clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:13:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:13:07 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.f5615d7d2d83a3a4bcb0cdeef55327e3@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So perhaps we need to carve out the bit that checks the coverage condition and just check that. Or just call `checkValidInstance` with a Note explaining why you might think it's not necessary (the exotic-derived Note), and the example from this ticket explaining why it actually is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:23:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:23:50 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.e243d16ba456e7f7ac75e9d1e8eec3a8@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Turns out there are a few places in the code that exploit `Maybe`'s `Monad` instance (using `do` notation). I'll keep those as `Maybe` for now and see where I end up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 09:35:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 09:35:52 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.2cc64d307139bba89416e21fcb72eb21@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.4.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe so, but it still should never happen! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 10:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 10:07:21 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.389466acfe965c5fef210f156954a23e@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: 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 RyanGlScott: Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` (ready, > http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) > * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) > * `directory` (ready, https://github.com/haskell/directory/pull/79) > * `filepath` (ready, https://github.com/haskell/filepath/pull/67) > * `ghc-boot-th` (ready, in-place) > * `ghc-compat` (ready, in-place) > * `ghci` (ready, in-place) > * `haddock` (ready, > https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) > * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/81) > * `hpc` (ready, > http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) > * `parsec` (awaiting, https://github.com/haskell/parsec/pull/90) > * `process` (ready, https://github.com/haskell/process/pull/124) > * `stm` (ready, https://github.com/haskell/stm/pull/7) > * `template-haskell` (ready, in-place) > * `terminfo` (awaiting, https://github.com/judah/terminfo/pull/30) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` (ready, http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) * `directory` (ready, https://github.com/haskell/directory/pull/79) * `filepath` (ready, https://github.com/haskell/filepath/pull/67) * `ghc-boot` (ready, in-place) * `ghc-boot-th` (ready, in-place) * `ghc-compact` (ready, in-place) * `ghci` (ready, in-place) * `haddock` (ready, https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (ready, https://github.com/judah/haskeline/pull/81) * `hpc` (ready, http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) * `parsec` (ready, https://github.com/haskell/parsec/commit/cd7a8e7abf30728f66365edb8fbbfb05fe3234ae) * `process` (ready, https://github.com/haskell/process/pull/124) * `stm` (ready, https://github.com/haskell/stm/pull/7) * `template-haskell` (ready, in-place) * `terminfo` (ready, https://github.com/judah/terminfo/pull/30) * `unix` (awaiting, https://github.com/haskell/unix/pull/108) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 10:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 10:41:56 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.256e8a3cca4ca0aa19672255459fe0f2@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): I’ll work on shrinking it further. And yes, I forgot to mention that core lint comes back fine and (on ghc Head) stg lint comes back fine as well. I’ve tried to consolidate the modules, but merging them all into a single module causes the problem to disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 10:47:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 10:47:07 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.21d55f9b2522086c6c9a1061d146c110@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` (ready, > http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) > * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) > * `directory` (ready, https://github.com/haskell/directory/pull/79) > * `filepath` (ready, https://github.com/haskell/filepath/pull/67) > * `ghc-boot` (ready, in-place) > * `ghc-boot-th` (ready, in-place) > * `ghc-compact` (ready, in-place) > * `ghci` (ready, in-place) > * `haddock` (ready, > https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) > * `haskeline` (ready, https://github.com/judah/haskeline/pull/81) > * `hpc` (ready, > http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) > * `parsec` (ready, > https://github.com/haskell/parsec/commit/cd7a8e7abf30728f66365edb8fbbfb05fe3234ae) > * `process` (ready, https://github.com/haskell/process/pull/124) > * `stm` (ready, https://github.com/haskell/stm/pull/7) > * `template-haskell` (ready, in-place) > * `terminfo` (ready, https://github.com/judah/terminfo/pull/30) > * `unix` (awaiting, https://github.com/haskell/unix/pull/108) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` (ready, http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) * `directory` (ready, https://github.com/haskell/directory/pull/79) * `filepath` (ready, https://github.com/haskell/filepath/pull/67) * `ghc-boot` (ready, in-place) * `ghc-boot-th` (ready, in-place) * `ghc-compact` (ready, in-place) * `ghci` (ready, in-place) * `haddock` (ready, https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (ready, https://github.com/judah/haskeline/pull/81) * `hpc` (ready, http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) * `parallel` (awaiting, https://github.com/haskell/parallel/pull/20) * `parsec` (ready, https://github.com/haskell/parsec/commit/cd7a8e7abf30728f66365edb8fbbfb05fe3234ae) * `process` (ready, https://github.com/haskell/process/pull/124) * `stm` (ready, https://github.com/haskell/stm/pull/7) * `template-haskell` (ready, in-place) * `terminfo` (ready, https://github.com/judah/terminfo/pull/30) * `unix` (awaiting, https://github.com/haskell/unix/pull/108) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Comment (by RyanGlScott): Oops, I declared victory too early. We still need to bump `parallel` and `unix`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 10:54:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 10:54:34 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.c7cb668cbb96c06e14ecec2c608c0c4f@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another thing I'm unclear on is: should we be calling `checkValidInstance` after //every// iteration of `simplifyDeriv`? Or should we only do it once, after the final inferred context has been found? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:15:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:15:18 -0000 Subject: [GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect Message-ID: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> #15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ rnIfaceBndr :: Rename IfaceBndr rnIfaceBndr (IfaceIdBndr (fs, ty)) = IfaceIdBndr <$> ((,) fs <$> rnIfaceType ty) rnIfaceBndr (IfaceTvBndr tv_bndr) = IfaceIdBndr <$> rnIfaceTvBndr tv_bndr }}} This is the implementation currently. Notice in the second branch that an `IfaceTvBndr` is converted to an `IfaceIdBndr`. Should it instead be `IfaceTvBndr`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:17:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:17:04 -0000 Subject: [GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect In-Reply-To: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> References: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> Message-ID: <064.4a72981418c876b146a3b2b26b4f4ac4@haskell.org> #15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 mpickering): See https://phabricator.haskell.org/D4600 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:25:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:25:03 -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.0c41972bca0f3ef255c9305f872691a3@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:25 simonpj]: > > Declare `catchRetry#` lazy in its first argument > > Great. So now we can dump all the `ThrowsExn` machinery! sgraf, are you up for doing that? I've added it to my queue. I can probably give it a higher priority, given that it's mostly syntactic and (hopefully) low effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:25:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:25:51 -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.ac6f1891d293a58852ea5b2db8405011@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 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): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:28:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:28:41 -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.f676bba6a42234fa2a1e604870eac145@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'd be happy to give that a crack if you like! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:30:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:30:53 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD Message-ID: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15018 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In order to perform a `unix` submodule bump (as requested in #15018), we'll need to deal with the fact that its major version number was bumped upstream to 2.8.0.0. As a result, the following boot libraries will need to be adjusted: * `Cabal` and `cabal-install` * `directory` * `haskeline` * `iserv-bin` (ready, in-place) * `process` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:31:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:31:13 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.fd65c2576645db3e61a82c640f6947a3@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 15042 Old description: > Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same > version of `base` as shipped with GHC 8.4.1). This is making it difficult > to adapt certain Hackage libraries to recent changes in `base`, such as > moving `Data.Functor.Contravariant` into `base` (see the discussion > [https://github.com/ekmett/contravariant/issues/44 here]). > > Before we can do this, here is a list of libraries that will need to have > their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: > > * `array` (ready, > http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) > * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) > * `directory` (ready, https://github.com/haskell/directory/pull/79) > * `filepath` (ready, https://github.com/haskell/filepath/pull/67) > * `ghc-boot` (ready, in-place) > * `ghc-boot-th` (ready, in-place) > * `ghc-compact` (ready, in-place) > * `ghci` (ready, in-place) > * `haddock` (ready, > https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) > * `haskeline` (ready, https://github.com/judah/haskeline/pull/81) > * `hpc` (ready, > http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) > * `parallel` (awaiting, https://github.com/haskell/parallel/pull/20) > * `parsec` (ready, > https://github.com/haskell/parsec/commit/cd7a8e7abf30728f66365edb8fbbfb05fe3234ae) > * `process` (ready, https://github.com/haskell/process/pull/124) > * `stm` (ready, https://github.com/haskell/stm/pull/7) > * `template-haskell` (ready, in-place) > * `terminfo` (ready, https://github.com/judah/terminfo/pull/30) > * `unix` (awaiting, https://github.com/haskell/unix/pull/108) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: Currently, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` (ready, http://git.haskell.org/packages/array.git/commit/234d0a11820c263c873e41810d7a4b9d6152dcec) * `deepseq` (ready, https://github.com/haskell/deepseq/pull/41) * `directory` (ready, https://github.com/haskell/directory/pull/79) * `filepath` (ready, https://github.com/haskell/filepath/pull/67) * `ghc-boot` (ready, in-place) * `ghc-boot-th` (ready, in-place) * `ghc-compact` (ready, in-place) * `ghci` (ready, in-place) * `haddock` (ready, https://github.com/haskell/haddock/commit/5b5058f958e6e141b9e9c12b6b79aaf218c210a7) * `haskeline` (ready, https://github.com/judah/haskeline/pull/81) * `hpc` (ready, http://git.haskell.org/packages/hpc.git/commit/91f520cb9725d812fa93b57bca1d8dbd72c88dd5) * `parallel` (ready, https://github.com/haskell/parallel/pull/20) * `parsec` (ready, https://github.com/haskell/parsec/commit/cd7a8e7abf30728f66365edb8fbbfb05fe3234ae) * `process` (ready, https://github.com/haskell/process/pull/124) * `stm` (ready, https://github.com/haskell/stm/pull/7) * `template-haskell` (ready, in-place) * `terminfo` (ready, https://github.com/judah/terminfo/pull/30) * `unix` (awaiting, https://github.com/haskell/unix/pull/108) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Comment: It looks like we'll need another round of submodule bumps to accommodate `unix-2.8.0.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:42:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:42:39 -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.ba64a161e42172705d85dbbf0a18386a@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:28 dfeuer]: > I'd be happy to give that a crack if you like! Sure then, it's all yours! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 11:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 11:53:20 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.860ab501d0fbaa5b31a654abba5f9662@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just at the end I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:03:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:03:45 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.e1947cb0123d5cdec094717548631b84@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): I have gotten it a little smaller. I've removed some functions from `Packed.Bytes.Parser`, and there are also no more levity polymorphic functions. Reminder about weird things: 1. Problems only happen when using `cabal` or `stack` to build, not when using ghc on its own. 2. Collapsing all modules into a single module (which affects inlining) makes the crash disappear. 3. This happens with `-O0` and `-O2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:05:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:05:25 -0000 Subject: [GHC] #15043: Expand type synonym Message-ID: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC 8.2.2 and `stack build --ghc-options=-fprint-expanded-synonyms` I have the following type synonym for servant: {{{#!hs type Get302 (cts :: [*]) (hs :: [*]) = Verb 'GET 302 cts (Headers (Header "Location" String ': hs) NoContent) }}} and get the following error message when `String` is mismatched for `Text`: {{{ • Couldn't match type ‘Text’ with ‘[Char]’ Expected type: AsServerT App :- ("login" :> ("callback" :> (QueryParam "code" Text :> (QueryParam "state" Text :> MyApp.Types.Servant.Get302 '[PlainText] '[Header "Set-Cookie" SetCookie, Header "Set-Cookie" SetCookie])))) Actual type: Maybe Code -> Maybe Text -> App (Headers '[Header "Location" Text, Header "Set- Cookie" SetCookie, Header "Set-Cookie" SetCookie] NoContent) }}} The error is confusing as type synonym is not expanded and offending `Header` is missing from the output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:08:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:08:06 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.a30c1d7b995f6a619d9206517bc50486@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by domenkozar: Old description: > Using GHC 8.2.2 and `stack build --ghc-options=-fprint-expanded-synonyms` > I have the following type synonym for servant: > > {{{#!hs > type Get302 (cts :: [*]) (hs :: [*]) = Verb 'GET 302 cts > (Headers (Header "Location" String ': hs) NoContent) > }}} > > and get the following error message when `String` is mismatched for > `Text`: > > {{{ > • Couldn't match type ‘Text’ with ‘[Char]’ > Expected type: AsServerT App > :- ("login" > :> ("callback" > :> (QueryParam "code" Text > :> (QueryParam "state" Text > :> MyApp.Types.Servant.Get302 > '[PlainText] > '[Header "Set-Cookie" > SetCookie, > Header "Set-Cookie" > SetCookie])))) > Actual type: Maybe Code > -> Maybe Text > -> App > (Headers > '[Header "Location" Text, Header "Set- > Cookie" SetCookie, > Header "Set-Cookie" SetCookie] > NoContent) > }}} > > The error is confusing as type synonym is not expanded and offending > `Header` is missing from the output. New description: Using GHC 8.2.2 and `stack build --ghc-options=-fprint-expanded-synonyms` I have the following type synonym for servant: {{{#!hs type Get302 (cts :: [*]) (hs :: [*]) = Verb 'GET 302 cts (Headers (Header "Location" String ': hs) NoContent) }}} and get the following error message when `String` is mismatched for `Text`: {{{ • Couldn't match type ‘Text’ with ‘[Char]’ Expected type: AsServerT App :- ("login" :> ("callback" :> (QueryParam "code" Text :> (QueryParam "state" Text :> MyApp.Types.Servant.Get302 '[PlainText] '[Header "Set-Cookie" SetCookie, Header "Set-Cookie" SetCookie])))) Actual type: Maybe Code -> Maybe Text -> App (Headers '[Header "Location" Text, Header "Set- Cookie" SetCookie, Header "Set-Cookie" SetCookie] NoContent) }}} The error is confusing as type synonym is not expanded and offending `Header` is missing from the output in the expected type. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:12:33 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.6b2ed09a05d22322739109f6d8221ed7@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): Here's my rudimentary analysis of the error message. {{{ internal error: evacuate(static): strange closure type 16648 }}} If this were caused by user code, I think it could only be the result of an out-of-bounds call to `writeArray`, `writeByteArray`, `readArray`, or `indexArray`. An out of bounds function that reads from a byte array would not cause this. It would simply give the user a garbage value. Well, I guess if it were far enough out-of-bounds, the operating system would kill the process, but that doesn't happen here. The function `writeByteArray` is used a few times, but all of its uses look safe to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:24:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:24:10 -0000 Subject: [GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect In-Reply-To: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> References: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> Message-ID: <064.8d63f009e9b6ed80c404ce7f22b3195c@haskell.org> #15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Bizarre. Seems so egregiously wrong that I'm astonished it ever worked. This code is only used by Backpack, however. Copying Edward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:33:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:33:12 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.ca25c28750af4bd70704497bd7f18732@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 osa1): I managed to reproduce this without stack or cabal. Steps: - Install dependencies: `cabal install containers split ghc-prim primitive` - Build the executable: `ghc-stage2 common/Data/Trie/Naive.hs src/Packed/Bytes.hs src/Packed/Bytes/Parser.hs src/Packed/Bytes/Small.hs src/Packed/Bytes/Stream/ST.hs src/Packed/Bytes/Window.hs test/Main.hs test/Parser.hs -fforce-recomp -o main` - Run `./main` It works fine with `-O0`, fails with `-O1` and `-O2`, but with different "strange closure" types. `-O1` prints 16661, `-O2` prints 16665. Even more interestingly I get a different number if I also add `-debug`: 16621. The object with "strange closure type" is a static one, and does not reside in heap. On my system it's at 0x967900. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 12:51:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 12:51:38 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.0ee6407c12ae88775ab0bc9b19b72267@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > In order to perform a `unix` submodule bump (as requested in #15018), > we'll need to deal with the fact that its major version number was bumped > upstream to 2.8.0.0. As a result, the following boot libraries will need > to be adjusted: > > * `Cabal` and `cabal-install` > * `directory` > * `haskeline` > * `iserv-bin` (ready, in-place) > * `process` > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: In order to perform a `unix` submodule bump (as requested in #15018), we'll need to deal with the fact that its major version number was bumped upstream to 2.8.0.0. As a result, the following boot libraries will need to be adjusted: * `Cabal` and `cabal-install` (awaiting, https://github.com/haskell/cabal/pull/5264) * `directory` (awaiting, https://github.com/haskell/directory/pull/81) * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/82) * `iserv-bin` (ready, in-place) * `process` (awaiting, https://github.com/haskell/process/pull/126) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 13:25:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 13:25:08 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.bf235e4433a152beab7c8b53f8f78975@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm. I tried to use `checkValidInstance`, but there's a big problem: its type signature is not very amenable to being put into `simplifyInstanceContexts`. It is [http://git.haskell.org/ghc.git/blob/fea04defa64871caab6339ff3fc5511a272f37c7:/compiler/typecheck/TcValidity.hs#l1303 currently]: {{{#!hs checkValidInstance :: UserTypeCtxt -> LHsSigType GhcRn -> Type -> TcM ([TyVar], ThetaType, Class, [Type]) }}} There are two awkward things about this: 1. It expects an `LHsSigType GhcRn` argument, but this isn't available in `simplifyInstanceContexts`. (However, `checkValidInstance` only uses this to get a `SrcSpan`, so perhaps this can be changed to just be a `SrcSpan` argument.) 2. A more awkward sticking point is that `checkValidInstance` expects a `Type` as an argument. This is because it then proceeds to split it with `tcSplitSigmaTy` (and returns the resulting tyvars and theta). However, in `simplifyInstanceContexts`, our instance type is already "pre-split" (that is, we already have the tyvars, theta, class, and class argument types lying around). What's worse, I can't just change the `Type` argument and replace it with the constituent `[TyVar]`, `ThetaType`, etc., since `checkValidInstance` passes that `Type` wholesale to `checkAmbiguity`. So I don't know what to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 13:50:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 13:50:18 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.c8a2bb1e52f3feabceba98020dfd1efd@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 14:14:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 14:14:52 -0000 Subject: [GHC] #15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release In-Reply-To: <042.4b53899d417f346d03c701660fddbf8b@haskell.org> References: <042.4b53899d417f346d03c701660fddbf8b@haskell.org> Message-ID: <057.02b0a5efad6c9733fd3117a37cae8321@haskell.org> #15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | 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: Hmm, not sure what happened here but there is little that can be done about it now. I've fixed this for 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 14:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 14:52:47 -0000 Subject: [GHC] #15044: Option to output instance resolution process Message-ID: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> #15044: Option to output instance resolution process -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple debug,typeclasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Would it be possible to see what instances get picked by the constraint solver? For example, see coq's `Set Typeclass Debug.`. The following comment also shows what it might look like: https://www.reddit.com/r/haskell/comments/8cmn4i/algorithmically_scrapping_your_typeclasses/dxg8fes/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:08:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:08:17 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.1f4b7522e9e7b7300d1e7e289a9848f7@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Is that the entirety of the error message? I ask because if I try using `-fprint-expanded-synonyms` on a smaller program, such as this one: {{{#!hs module Bug where type Foo = Int f :: Maybe Foo f = Just 'a' }}} I get this: {{{ $ ghc Bug.hs -fprint-expanded-synonyms [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:5: error: • Couldn't match type ‘Char’ with ‘Int’ Expected type: Maybe Foo Actual type: Maybe Char Type synonyms expanded: Expected type: Maybe Int Actual type: Maybe Char • In the expression: Just 'a' In an equation for ‘f’: f = Just 'a' | 6 | f = Just 'a' | ^^^^^^^^ }}} Notice that there is a separate `Type synonyms expanded` section which shows `Maybe Int` instead of `Maybe Foo`. Does GHC not show this in your example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:09:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:09:54 -0000 Subject: [GHC] #14750: Plugins should be loaded once for each module rather than multiple times In-Reply-To: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> References: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> Message-ID: <064.bf01c06aca92eb0779ce35f920ab530f@haskell.org> #14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: plugins Operating System: 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 `-ddump-cs-trace`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:10:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:10:30 -0000 Subject: [GHC] #15044: Option to output instance resolution process In-Reply-To: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> References: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> Message-ID: <059.af2f2c9baaddccd2f2f9323030e12abe@haskell.org> #15044: Option to output instance resolution process -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | debug,typeclasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12687 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #12687 Comment: Perhaps `-ddump-cs-trace`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:11:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:11:33 -0000 Subject: [GHC] #14750: Plugins should be loaded once for each module rather than multiple times In-Reply-To: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> References: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> Message-ID: <064.d9964f8919105c80c6887ea81cc59925@haskell.org> #14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: plugins 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: This was fixed in f8e3cd3b160d20dbd18d490b7babe43153bb3287 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:18:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:18:48 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.f038cb5bc734c8eb9fc541aae9521be6@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by goldfire): Iavor asked on the mailing lists about this example: {{{#!hs {-# Language TypeInType, TypeFamilies #-} module Help where import Data.Kind type family IxKind (m :: Type) :: Type type family Value (m :: Type) :: IxKind m -> Type data T (k :: Type) (f :: k -> Type) type instance IxKind (T k f) = k type instance Value (T k f) = f }}} Currently, you have to put a `$(return [])` between the two instances to get GHC to accept. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:19:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:19:33 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.222bea1b3d221bae9d3ee58e855e9800@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): D4568 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => tdammers Comment: Tobias will look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:19:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:19:44 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.f25e82cb0e13cbe55651f3eee0c4f317@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D4568 => phab:D4568 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:38:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:38:15 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.95fee44d2b7d0a268fc7d989b3e3fe8d@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by tdammers): Add a stripped-down version of Grammar.hs as a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:41:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:41:49 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.2ea333328bfc3673c8ef640c16edfdd0@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon suggests `-dshow-passes` comparing iterations in different GHC versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 15:44:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 15:44:38 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.09a8e934094ebcccc92551d8a3f28556@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Get back to bullet 1 of comment 9! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 16:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 16:05:51 -0000 Subject: [GHC] #15045: Remove broken top-level shell.nix Message-ID: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> #15045: Remove broken top-level shell.nix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4599 | Wiki Page: -------------------------------------+------------------------------------- The shell.nix in the root directory is quite broken. The one at hadrian/shell.nix should be used. I'm not even sure how that shell.nix ended up there. I don't remember adding it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 16:05:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 16:05:59 -0000 Subject: [GHC] #15045: Remove broken top-level shell.nix In-Reply-To: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> References: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> Message-ID: <064.6b71a00aac53ff57e8dbb8dce0f01679@haskell.org> #15045: Remove broken top-level shell.nix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Phab:D4599 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): See https://phabricator.haskell.org/D4599 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 16:45:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 16:45:34 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.2d0201c3f762ab116d42b281397b66c9@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that this will require someone (Ben?) to manually update the mirrors of `haskeline` and `terminfo` at http://git.haskell.org/packages/haskeline.git and http://git.haskell.org/packages/terminfo.git, respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 18:58:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 18:58:59 -0000 Subject: [GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be In-Reply-To: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> References: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> Message-ID: <065.0b8aadb672a35987672d283572e51b42@haskell.org> #15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by parsonsmatt): I should have used a less minimal example, I think I didn't adequately demonstrate the problem :) I ran into this while working on a DSL for database definitions, and I'm using `RecursiveDo` to allow table references out of order. I am also using an `ST` token trick to ensure that field references don't escape their table. Here's a snippet of the DSL: {{{#!hs example :: Schema example = mdo let theUsual = derive @[Eq, Ord, Show] table_ "Dog" $ do owner <- field "owner" userRef field "name" (typ @String) foreignKey userRef "fk_dog_user" [owner] derive @[Eq, Ord, Show] userRef <- table "User" $ do field "name" (typ @String) field "age" (typ @Int) ! "do people use attribute?" ! "i hope so" theUsual table_ "Friend" $ do _ <- field "foobar" (typ @Int) name <- field "name" (typ @Int) ugh <- field "ugh" (typ @Int) unique "FriendName" name primary ugh theUsual }}} This works fine. However, if I move `theUsual` definition to below the `table_ "Dog"` block: {{{#!hs example = mdo table_ "Dog" $ do owner <- field "owner" userRef field "name" (typ @String) foreignKey userRef "fk_dog_user" [owner] derive @[Eq, Ord, Show] let theUsual = derive @[Eq, Ord, Show] userRef <- table "User" $ do field "name" (typ @String) field "age" (typ @Int) ! "do people use attribute?" ! "i hope so" theUsual table_ "Friend" $ do _ <- field "foobar" (typ @Int) name <- field "name" (typ @Int) ugh <- field "ugh" (typ @Int) unique "FriendName" name primary ugh theUsual }}} I get the following error: {{{ /home/matt/Projects/mesa-verde/src/MesaVerde/Internal.hs:59:9: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. EntityDefine s () at src/MesaVerde/Internal.hs:(51,5)-(59,16) Expected type: EntityDefine s () Actual type: EntityDefine s0 () • In a stmt of a 'do' block: theUsual In the second argument of ‘($)’, namely ‘do _ <- field "foobar" (typ @Int) name <- field "name" (typ @Int) ugh <- field "ugh" (typ @Int) unique "FriendName" name ....’ In a stmt of an 'mdo' block: table_ "Friend" $ do _ <- field "foobar" (typ @Int) name <- field "name" (typ @Int) ugh <- field "ugh" (typ @Int) unique "FriendName" name .... • Relevant bindings include ugh :: FieldRef s (bound at src/MesaVerde/Internal.hs:54:9) name :: FieldRef s (bound at src/MesaVerde/Internal.hs:53:9) theUsual :: EntityDefine s0 () (bound at src/MesaVerde/Internal.hs:41:9) | 59 | theUsual | ^^^^^^^^ }}} It seems that it is floating `theUsual` into one of the blocks, causing the phantom type to infer as local to one of the blocks, and only allows it to be used in one block at a time. Switching to `do` instead of `mdo` fixes the problem (though it also forbids circular references, which I need). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 21:19:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 21:19:13 -0000 Subject: [GHC] #15044: Option to output instance resolution process In-Reply-To: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> References: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> Message-ID: <059.d41ec59a425bcc4c99e8d0a3245905af@haskell.org> #15044: Option to output instance resolution process -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | debug,typeclasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12687 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lyxia): That looks like it! Is it not documented because it still needs work? I can see the constraints that must be solved at every step, but it would also be nice to see what instances actually get picked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 22:13:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 22:13:53 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.d246b3065d24ac34f0f2d402a1e05d64@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Its a bit crude, but you could readily make the type to pass to `checkValidInstance` by saying `mkSigmaTy tyvars theta the_pred`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 16 22:16:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Apr 2018 22:16:59 -0000 Subject: [GHC] #15044: Option to output instance resolution process In-Reply-To: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> References: <044.3db3f8e5034bcc93c64c9b88a02b341b@haskell.org> Message-ID: <059.b289fc3ef8d8fbacbeaa48f2fa252938@haskell.org> #15044: Option to output instance resolution process -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | debug,typeclasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12687 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `-ddump-cs-trace` is really intended for people debugging the constraint solver, rather than programmers. But something very like it should work just fine. It just needs someone to have a go... feel free to ask questions. I think the tricky bit would be identifying the constraint being solved in a way that is meaningful to the programmer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 08:40:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 08:40:53 -0000 Subject: [GHC] #11117: mdo blocks in error messages are shown modified In-Reply-To: <046.ec212f85b7979e3faf4311226423edaa@haskell.org> References: <046.ec212f85b7979e3faf4311226423edaa@haskell.org> Message-ID: <061.5c661ad977fdc1b60bc464d68d448ae4@haskell.org> #11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: RecursiveDo Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => RecursiveDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 08:41:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 08:41:01 -0000 Subject: [GHC] #7842: Incorrect checking of let-bindings in recursive do In-Reply-To: <047.6ed6f6679c4518c532948e013c23eaed@haskell.org> References: <047.6ed6f6679c4518c532948e013c23eaed@haskell.org> Message-ID: <062.08bf58ca43833c0785aac5d322d8c1b0@haskell.org> #7842: Incorrect checking of let-bindings in recursive do -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: RecursiveDo 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 simonpj): * keywords: => RecursiveDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 08:41:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 08:41:35 -0000 Subject: [GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be In-Reply-To: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> References: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> Message-ID: <065.83e7e647252e22f3dc4644b7699bd81c@haskell.org> #15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: RecursiveDo 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: => RecursiveDo Comment: That is indeed odd. Are you sure your example is right in comment:2? You don't even use `theUsual` before its definition in the "However, when I move..." version. The `weiddlyLocal` example in the Description is more comprehensible. After dependency analysis we get {{{ thisWorks :: IO () thisWorks = do let weirdlyLocal1 = theThing runSTIO weirdlyLocal1 runSTIO weirdlyLocal1 thisBreaks :: IO () thisBreaks = do rec { runSTIO weirdlyLocal2 ; let weirdlyLocal2 = theThing runSTIO weirdlyLocal2 } }}} I've made the recursive block explicit. No `rec` is needed in the first example, and we get {{{ weirdlyLocal1 :: forall s. ST s () }}} But in the second example we have recursion, and like all reduction (at least without type signatures) in Haskell, it is monomorphic. So in the recursive block we get {{{ weirdlyLocal2 :: ST s0 () }}} where `s0` is some monomorphic type. So `weirdlyLocal2` is not polymoprhic enough to give to `runSTIO`, hence breakage. Another way to think of it is to imagine typing this: {{{ thisBreaks = do weirdlyLocal2 <- mfix (\wl2 -> do { runSTIO wl2 ; let weirdlyLocal2 = theThing ; return weirdlyLocal2 }) runSTIO weirdlyLocal2 } }}} Here you can see that the lambda-bound `wl2` would get a monormorphic type. I don't think anyone has studied how to do ''polymorphic'' recursion in `mdo`. But it'd be interesting to try. Trac #7842 is another report of the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 10:00:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 10:00:13 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 In-Reply-To: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> References: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> Message-ID: <067.5dcf7ea46b57b8416a5ae8ef7989d9dc@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): I've built 8.4 against llvm6. While it keeps emitting warnings, the built went through and building a simple Hello World application did work fine. I didn't have time to run validate just yet. And I won't until the end of the month as I'm stuck with a portable (slow) laptop until then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 11:28:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 11:28:52 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.a2656e8a2746af016ab6ce6589272de5@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | 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 Tue Apr 17 12:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 12:06:10 -0000 Subject: [GHC] #15046: Broken links on haskell.org/ghc Message-ID: <051.348b6adb891ed6d6f85cbdd2679cf31d@haskell.org> #15046: Broken links on haskell.org/ghc -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://www.haskell.org/ghc/ haskell.org/ghc] has broken links in the menu (sidebar on the left). The ones concerning Track: * Report a bug * Request a feature * Developers (Wiki) All point to Hackage for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 12:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 12:15:52 -0000 Subject: [GHC] #15047: Outdated comments in RnSource.hs Message-ID: <051.604d8168c116eeada5fd68f1d874f4df@haskell.org> #15047: Outdated comments in RnSource.hs -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4596 | Wiki Page: -------------------------------------+------------------------------------- While reading sources of the Renamer I noticed some comments which seem to be irrelevant now. The body of `rnSrcDecls` (`RnSource.hs`) is broken up in several “parts” (A, B, etc.). #b1884b0e6 removed what is used to be called part (C) — the use of `extendRecordFieldEnv`, with the following comment in Phab:D761: > Get rid of `extendRecordFieldEnv`, do it in `getLocalNonValBinders` instead (Note: `getLocalNonValBinders` belongs to part (B)). At the same time, the references to this part (C) remained in comments to other "parts" (B and D2). Removing these references will save inexperienced reader from confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 12:43:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 12:43:42 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.6404e448c49e20d04d020ded23a6c41f@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > In order to perform a `unix` submodule bump (as requested in #15018), > we'll need to deal with the fact that its major version number was bumped > upstream to 2.8.0.0. As a result, the following boot libraries will need > to be adjusted: > > * `Cabal` and `cabal-install` (awaiting, > https://github.com/haskell/cabal/pull/5264) > * `directory` (awaiting, https://github.com/haskell/directory/pull/81) > * `haskeline` (awaiting, https://github.com/judah/haskeline/pull/82) > * `iserv-bin` (ready, in-place) > * `process` (awaiting, https://github.com/haskell/process/pull/126) > > Some of these can be changed in-place, while others will require > downstream changes. I'll update this ticket as I progress. New description: In order to perform a `unix` submodule bump (as requested in #15018), we'll need to deal with the fact that its major version number was bumped upstream to 2.8.0.0. As a result, the following boot libraries will need to be adjusted: * `Cabal` and `cabal-install` (ready, https://github.com/haskell/cabal/pull/5264) * `directory` (ready, https://github.com/haskell/directory/pull/81) * `haskeline` (ready, https://github.com/judah/haskeline/pull/82) * `iserv-bin` (ready, in-place) * `process` (ready, https://github.com/haskell/process/pull/126) Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 12:44:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 12:44:38 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.9a451bb9640bbaaaaceb5e6e4715122f@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is blocked on updating the mirror at http://git.haskell.org/packages/haskeline.git . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 12:53:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 12:53:19 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.8ed016272daae91986ba4ff5d3866608@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks plausible to me, but needs a careful Note to explain the issues. But before we go too far with this, I'd like to point to [wiki:LateLamLift late lambda lifting]. In the core reported in comment:44, all we need to do is lambda-lift `$wc` and `go_up` to top level, and all will be well, I claim. And that is precisely what late-lambda lifting does. And the result might be faster than the very careful code above, because of the extra argument passing and case-tesing it has to do. To me LLF is low-hanging fruit. There are promising results described on the wiki page, and the whole join-point business eliminates its principal shortcoming. I wonder if, before going ahead with this somewhat-delicate `efdtIntFB` business, it might be fun to re-awaken LLF? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 13:02:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 13:02:26 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.eb718367de01553f08de1c21b2065ea9@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > #14737, while drastically improving performance on some edge cases, > introduces performance regressions in 3 test cases: > > perf/compiler/parsing001.run > perf/compiler/T9020.run > perf/compiler/T12707.run New description: #14737, while drastically improving performance on some edge cases, introduces performance regressions in 3 test cases: * perf/compiler/parsing001.run * perf/compiler/T9020.run * perf/compiler/T12707.run -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 13:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 13:09:46 -0000 Subject: [GHC] #15046: Broken links on haskell.org/ghc In-Reply-To: <051.348b6adb891ed6d6f85cbdd2679cf31d@haskell.org> References: <051.348b6adb891ed6d6f85cbdd2679cf31d@haskell.org> Message-ID: <066.fb001cbdb2c8abf0ba57bf57a3d1cf70@haskell.org> #15046: Broken links on haskell.org/ghc -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for the bug report, although this might be better suited for https://github.com/haskell-infra/ghc-homepage/issues than Trac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 13:20:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 13:20:38 -0000 Subject: [GHC] #15046: Broken links on haskell.org/ghc In-Reply-To: <051.348b6adb891ed6d6f85cbdd2679cf31d@haskell.org> References: <051.348b6adb891ed6d6f85cbdd2679cf31d@haskell.org> Message-ID: <066.a65e4707a380f2bc8fac90f07540254f@haskell.org> #15046: Broken links on haskell.org/ghc -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Trac & Git | Version: 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 ulysses4ever): * status: new => closed * resolution: => invalid Comment: Thanks for pointing that out! [https://github.com/haskell-infra/ghc- homepage/issues/6 Reported]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 13:55:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 13:55:20 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.d42c2cbf17997dec5184147ed88f61a9@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've hit another snag, related to comment:15. I tried putting the call to `checkValidInstance` after `simplifyDeriv` has finished iterating, but that doesn't work for the original program in this ticket. Why? Because during the second iteration of `simplifyDeriv`, we pass the context `C b a` (the result of the first iteration of `simplifyDeriv`) to `solveWantedsAndDrop`. But that leads to the infinite loop described in comment:2, so it's already too late by that point. Naturally, I thought to instead try calling `checkValidInstance` after //every// iteration of `simplifyDeriv`. This does fix the original program, but it causes `T4809.hs` to fail instead. The reason is because of this derived instance: {{{#!hs newtype XMLGenT m a = XMLGenT (m a) deriving (MonadRWS r w s) }}} After the first iteration of `simplifyDeriv`, it produces the context `Monoid w`. We then pass the following instance to `checkValidInstance`: {{{#!hs instance Monoid w => MonadRWS r w s (XMLGenT m) }}} But this doesn't satisfy the coverage condition for `MonadRWS`'s fundeps! (We need `m -> r`, `m -> w`, and `m -> s`.) The final context for this instance, `(MonadReader r m, MonadWriter w m, MonadState s m)`, //does// satisfy the coverage condition, but we don't get this until after a later iteration of `simplifyDeriv`. To sum it up: I can't call `checkValidInstance` at the end, since an intermediate context might throw the simplifier into a loop, but I can't call `checkValidInstance` in the middle either, since an intermediate context might not satisfy the coverage condition. I don't know how to proceed from here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:09:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:09:45 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.dd594be361c108691b07f978d8ed88e8@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer 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 ckoparkar): Ben, did you get a chance to take a look at this ? Does this seem like the right thing to do ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:21:55 -0000 Subject: [GHC] #15047: Outdated comments in RnSource.hs In-Reply-To: <051.604d8168c116eeada5fd68f1d874f4df@haskell.org> References: <051.604d8168c116eeada5fd68f1d874f4df@haskell.org> Message-ID: <066.ddea3f4c137c840c611f5ee17db18cc8@haskell.org> #15047: Outdated comments in RnSource.hs -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4596 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fe325d3dc3750274c742b9814bf7915f17546e7c/ghc" fe325d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe325d3dc3750274c742b9814bf7915f17546e7c" Comments only Deleting misleading comments, to fix Trac #15047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:25:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:25:05 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.11700edcf9c24d3bd9bb1d063cc46b3b@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe you want dis-aggregate `checkValidInstance`. * I think you need `checkInstTermination` on every iteration. Probably even if `UndecidableInstances` is on; I'm not sure that automatic deriving should ever generate a non-provably-terminating instance. * Then you can call `checkValidInstance` itself right at the end -- that will check the coverage conditions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:25:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:25:30 -0000 Subject: [GHC] #15047: Outdated comments in RnSource.hs In-Reply-To: <051.604d8168c116eeada5fd68f1d874f4df@haskell.org> References: <051.604d8168c116eeada5fd68f1d874f4df@haskell.org> Message-ID: <066.790fe79cd20ff3eae9ea376a2d1dfb99@haskell.org> #15047: Outdated comments in RnSource.hs -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4596 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good catch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:31:32 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.d606f21e9110ecd03f4f7a97d0f9c185@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4602 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:36:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:36:40 -0000 Subject: [GHC] #5129: "evaluate" optimized away In-Reply-To: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> References: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> Message-ID: <058.3a24510a84e12c215970f7b0fcf999ae@haskell.org> #5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Comment (by bgamari): George, indeed we do. Alp has recently been working on cleaning up the `./validate --slow` output (#14890) so we can run it during CI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:43:49 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.7724593c1d019b752abb73fedf1b50c4@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm afraid that won't work either. `checkInstTermination` only checks the Paterson termination conditions, not the fundep coverage conditions (which are checked separately in `checkInstCoverage`). Indeed, I just tried calling `checkInstTermination` after every iteration of `simplifyDeriv`, but the original program still loops even with that, since `C b a` passes the Paterson termination conditions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:44:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:44:58 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.86b8c905d20ec7524a4a7840c08de3f9@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I added a suggestion on the Phab, but it is (still, alas) not broadcast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:59:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:59:43 -0000 Subject: [GHC] #15048: Fix mirroring of terminfo and haskeline Message-ID: <046.c3a7e83293fc0e262628d22ca9c5dd3f@haskell.org> #15048: Fix mirroring of terminfo and haskeline -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Trac & Git | Version: 8.2.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: -------------------------------------+------------------------------------- These seem not to mirror from GitHub to git.haskell.org automatically, unlike most of the boot libraries. Looking at the mirroring configuration it appears that it was never configured for these packages, but there is no indication as to why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 14:59:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 14:59:55 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.c362a3c6560bc2ea8610a1674cabd9c7@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Done. Hvr, do you recall why these two packages in particular aren't mirrored automatically? I've opened #15048 to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:02:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:02:04 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.57d591cb3a8834ea33ed225f8ab17b8d@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I'm not sure what to do. 1 You don't want 'deriving' to loop 2 If the fundep coverage condition isn't satisfied, instance resolution can go into a loop, 3 But comment:18 says that you want 'deriving' to work when fundep coverage doesn't hold. Perhaps (2) is over-conservative, somehow? Presumably there is something special about (3) that makes it terminate, despite (2) not holding. If you can identify what that is, you can make that into a new (more expressive) fundep coverage condition. Iavor is the fundep expert. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:06:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:06:29 -0000 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> References: <050.49e5533b97232a9f431fe6cab3b29ebd@haskell.org> Message-ID: <065.1e8a4fbe1311abcdc4f1593d4f40dd5e@haskell.org> #2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: Yes, I think so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:07:30 -0000 Subject: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation In-Reply-To: <048.bcd71639490682a6b2cce6627a019c28@haskell.org> References: <048.bcd71639490682a6b2cce6627a019c28@haskell.org> Message-ID: <063.f148dc727f085eebda5eb7ad369b7a3c@haskell.org> #4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 6.12.3 Resolution: fixed | Keywords: MVar Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Alright, then let's go ahead and close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:09:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:09:05 -0000 Subject: [GHC] #14964: performance regressions from 8.0.2 to 8.4.1 In-Reply-To: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> References: <047.90da086f6f6ef4027330151b41f8cc58@haskell.org> Message-ID: <062.05e792657d0fe9460e3c19343cddc660@haskell.org> #14964: performance regressions from 8.0.2 to 8.4.1 -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Digging into this is next on my priority list, but it's a hobby project and I'm starting a new job so give me a few weeks. Great, thank you. We'll wait to hear more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:11:56 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.44272f6da4212c3c55ca1c72fbb1a2b0@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: diatchki (added) Comment: Indeed, I suspect we need a more permissive check than `checkInstCoverage` which would reject `C b a` but not `Monoid w` in the `XMLGenT` example. Alas, I have no idea what that check would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:12:33 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.2d74b4038c3db2b9d3ab5e28cee2dcf0@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Any chance of getting the behaviour to omit () added back? This doesn't seem to have much to do with the Description! I have no idea what the old behaviour is, what the new behaviour is, or which patch made the change that you object to. Would you like give a short ab-initio specification of the change you want? It does not sound controversial or hard to implement. Maybe you can offer a patch too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:14:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:14:36 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.9081b4dc38fea77ababc17e168985393@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | 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 echatav): I also have a use case for labels starting with uppercase letters. It would be extremely helpful for supporting PostgreSQL enum types which are compatible with Haskell enum types in Squeal (https://hackage.haskell.org/package/squeal-postgresql). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:14:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:14:54 -0000 Subject: [GHC] #5252: UNPACK without optimisation leads to panic In-Reply-To: <046.197b10301a44159175d2cccd7c28dcbc@haskell.org> References: <046.197b10301a44159175d2cccd7c28dcbc@haskell.org> Message-ID: <061.7040c8d8a29c7b1edae5e074158ddba8@haskell.org> #5252: UNPACK without optimisation leads to panic -------------------------+------------------------------------------------- Reporter: | Owner: (none) simonpj | Type: bug | Status: closed Priority: | Milestone: 7.6.2 normal | Component: | Version: 7.6.1 Compiler | Resolution: | Keywords: fixed | Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: deSugar/should_compile/T5252, None/Unknown | T5252Take2 Blocked By: | Blocking: Related Tickets: | -------------------------+------------------------------------------------- Comment (by Ben Gamari ): In [changeset:"4a168043f1b584dc201b5af48870ab6498b8a830/ghc" 4a16804/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a168043f1b584dc201b5af48870ab6498b8a830" Fix markup in the UNPACK pragma section of the user's guide. The ticket 5252 wasn't linked earlier. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:16:50 -0000 Subject: [GHC] #14987: Memory usage exploding for complex pattern matching In-Reply-To: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> References: <047.01959a6ab9a68448aba5b4dbc4570db8@haskell.org> Message-ID: <062.9cfcd715d3e31fe6d1bbcb6a3d219854@haskell.org> #14987: Memory usage exploding for complex pattern matching -------------------------------------+------------------------------------- Reporter: vmiraldo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: | PatternMatchWarnings 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: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:24:20 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.6cb7d917b6d919fc646248c251729952@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by tdammers): Simon PJ suggested: Try isReflCo rather than discarding the tyL=tyR guard altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:26:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:26:30 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.7155312b138d0c1407ec25464197b6af@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 simonpj): Yes, using a precedence argument must be the Right Thing. We do this in quite a few places, notably `TyCoRep` and even `RtClosureInspect` and `Debugger`. Maybe the thing to do is to have {{{ newtype PprPrec = Prec Int deriving( Eq, Ord ) }}} in `BasicTypes` or `Outputable`, and use it for everything. Then we can have local defns like {{{ topPrec = 0 funPrec = 1 ... }}} and the various applications of it won't conflict with each other. Maybe `topPrec` can be shared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:28:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:28:32 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper Message-ID: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- AMD's Threadripper can be configured to be a 1-socket 2-die NUMA system: Coreinfo.exe: {{{ Logical to Physical Processor Map: **------------------------------ Physical Processor 0 (Hyperthreaded) --**---------------------------- Physical Processor 1 (Hyperthreaded) ----**-------------------------- Physical Processor 2 (Hyperthreaded) ------**------------------------ Physical Processor 3 (Hyperthreaded) --------**---------------------- Physical Processor 4 (Hyperthreaded) ----------**-------------------- Physical Processor 5 (Hyperthreaded) ------------**------------------ Physical Processor 6 (Hyperthreaded) --------------**---------------- Physical Processor 7 (Hyperthreaded) ----------------**-------------- Physical Processor 8 (Hyperthreaded) ------------------**------------ Physical Processor 9 (Hyperthreaded) --------------------**---------- Physical Processor 10 (Hyperthreaded) ----------------------**-------- Physical Processor 11 (Hyperthreaded) ------------------------**------ Physical Processor 12 (Hyperthreaded) --------------------------**---- Physical Processor 13 (Hyperthreaded) ----------------------------**-- Physical Processor 14 (Hyperthreaded) ------------------------------** Physical Processor 15 (Hyperthreaded) Logical Processor to Socket Map: ******************************** Socket 0 Logical Processor to NUMA Node Map: ****************---------------- NUMA Node 0 ----------------**************** NUMA Node 1 Approximate Cross-NUMA Node Access Cost (relative to fastest): 00 01 00: 1.0 1.4 01: 1.7 1.2 }}} However, ghc-8.4.1 doesn't detect the NUMA topology when running with `--numa` {{{ ghc.EXE: --numa: OS reports NUMA is not available }}} I haven't attempted dualbooting into Linux, yet, so I can't tell whether it's a Windows-only issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:29:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:29:56 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down In-Reply-To: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> References: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> Message-ID: <059.227775f6deeea1156aa751e9501af7a7@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4603 Comment: Hmm, I suppose we could override the default `mathjax_path` in the Sphinx configuration. This feels like a bit of a bandaid though. See Phab:D4603. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:31:16 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.c66f8f3c8500f827c56bcf2fedf53ae5@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): Indeed. As currently designed, however, `TyPrec` doesn't fit neatly into this `PprPrec` paradigm, since the `Eq`/`Ord` instances for `TyPrec` treat `FunPrec` and `TyOpPrec` as having the same precedence (but they still need to be separate constructors, so sayeth [http://git.haskell.org/ghc.git/blob/cab3e6bfa8486c6c8eecac269c54d662f1371a0c:/compiler/basicTypes/BasicTypes.hs#l746 this note]). But in any case, I don't think I need to touch anything `Type`-related in this patch to begin with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:34:54 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.5fb30f1ecb5338b202fb88cdfda55081@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.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 bgamari): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:38:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:38:02 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.d76f76fe54cd7e5800c61436049b68cf@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -----------------------------------+---------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556 Wiki Page: | -----------------------------------+---------------------------------- Changes (by bgamari): * cc: Jaffacake (added) Comment: Yes, that is perhaps a reasonable way forward. Jaffacake, any objection? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:38:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:38:59 -0000 Subject: [GHC] #12982: Missed constant folding oportunities In-Reply-To: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> References: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> Message-ID: <059.f65a9e3e941dac8420d367a0044e6345@haskell.org> #12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/hoopl | 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): Hi Vyse007, do you think you could push your patch to Phabricator so I can have a look. Thanks for picking this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:41:08 -0000 Subject: [GHC] #14988: Memory strain while compiling HLint In-Reply-To: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> References: <046.841e8f99e82b8877c23858d1ca47b3db@haskell.org> Message-ID: <061.e0a2d4dd8632f5bf8fa865a26c2f5e2d@haskell.org> #14988: Memory strain while compiling HLint -------------------------------------+------------------------------------- Reporter: mcandre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Have you tried compiling with `-O0`? This may help memory consumption considerably. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:41:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:41:57 -0000 Subject: [GHC] #14997: mut_list_size calculation is off In-Reply-To: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> References: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> Message-ID: <058.32b8b931618da0e862282b88f3e839c0@haskell.org> #14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: 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 (removed) * cc: Jaffacake (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:48:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:48:01 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.415d129adc0f53f00cbf879d0929aa49@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer 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): ckoparkar, thanks for the ping. Indeed I missed your comments. I suppose we could move this to `base` (e.g. `GHC.ResponseFile`). It's a bit unfortunately that `Cabal` will then depend upon a GHC-specific interface, but it doesn't make sense to introduce a new library just for this functionality. You could ask Michael whether he would accept it in `process`, although I'm not sure how many users it would have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:56:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:56:27 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.583e371b6ceaa93c968223f32224124c@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 15:56:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 15:56:36 -0000 Subject: [GHC] #14972: MacOS panic on TH In-Reply-To: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> References: <050.216fa0d0ad85b79e36c3fe0a299b4fca@haskell.org> Message-ID: <065.270c6ca219d01979d80298bc2dd13f9f@haskell.org> #14972: MacOS panic on TH -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.1 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:D4553 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:21:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:21:45 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.3c7237f899cf9063df194360cfee4165@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Phab:D4604 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4604 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:24:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:24:45 -0000 Subject: [GHC] #12152: panic: Loading temp shared object failed In-Reply-To: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> References: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> Message-ID: <062.38a5f906ceef23ec19468e86538b1567@haskell.org> #12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 7.8.1 (Linking) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: I'm going to close this under the assumption that it is fixed. Feel free to reopen if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:25:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:25:07 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.9aebfce8c3985a52714bf5636d35ab49@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > While trying to launch ghci got the following error: > > ❯ stack ghci > The following GHC options are incompatible with GHCi and have not been > passed to it: -threaded -Odph > Using main module: 1. Package `line-segment-intersection' component > exe:demo with main-is file: > /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs > Configuring GHCi with the following packages: line-segment-intersection, > GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.3 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, > 5): Symbol not found: _bdf_driver_class > Referenced from: > /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib > Expected in: flat namespace > in > /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: While trying to launch ghci got the following error: {{{ ❯ stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib 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 Tue Apr 17 16:26:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:26:13 -0000 Subject: [GHC] #11045: Loading temp shared object failed - undefined symbol In-Reply-To: <046.9d39dd7431e7e6dfe6663e1ceca6d812@haskell.org> References: <046.9d39dd7431e7e6dfe6663e1ceca6d812@haskell.org> Message-ID: <061.2bd09ea5c7a2c02035309e29fdc0fa6d@haskell.org> #11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:27:45 -0000 Subject: [GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files In-Reply-To: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> References: <048.42d4a7f7acd8ddc9572d2421e0cac286@haskell.org> Message-ID: <063.5962937e0fd682a61331dd08d4f24d7c@haskell.org> #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files -------------------------------------+------------------------------------- Reporter: massysett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Linking) | Resolution: | Keywords: 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 a package that bundles in C library sources. I never had a > problem with this when using GHC 7.6. > > In GHC 7.8, the order of the c-sources in the cabal file now matters. > Sources must be listed earlier if they have symbols that subsequently > loaded object files will need. If the c-sources are in the wrong order, > when running "cabal repl" I get > > Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: > panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-linux): > Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: > undefined symbol: DECSTICKYTAB > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > When using the same code and cabal file with GHC 7.6, "cabal repl" works > fine: GHCi loads each static object (regardless of ordering in the cabal > file), links up the necessary symbols, and launches successfully. > > Haskell Cafe discussion here: > > http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html New description: I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get {{{ Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:30:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:30:33 -0000 Subject: [GHC] #14713: GHCi doesn't load project. In-Reply-To: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> References: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> Message-ID: <069.1cb325de76313c380eda358986f0097a@haskell.org> #14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.6.1 Comment: It looks like the issue here is that GHC is trying to load the temporary Haskell objects before it loads the C objects. In GHC's defense, Cabal does list the C objects after the modules in the command line that it produces. It seems to me like GHC should likely first load any C objects, then compile and load the Haskell modules requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:36:43 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.14f5f3f0c809e76eeaf0f09db506137e@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by bgamari): Hmm, interesting. Note that on Linux NUMA support requires that the compiler be built with `libnumactl` support, which the provided binary distributions are not. However, this ought to just work on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 16:59:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 16:59:36 -0000 Subject: [GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be In-Reply-To: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> References: <050.07f3eeb0ac5e987001f250deddbab896@haskell.org> Message-ID: <065.7c9d862f06337cb0bbe0883c6b9f2c3b@haskell.org> #15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: RecursiveDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by parsonsmatt): > That is indeed odd. Are you sure your example is right in comment:2? You don't even use theUsual before its definition in the "However, when I move..." version. Yes. [https://github.com/parsonsmatt/mesa- verde/blob/81d2fb68ec87ff3f97eed1463f86f5f7e0b77240/src/MesaVerde/Internal.hs This is a repository] containing all of the code and definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 17:01:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 17:01:09 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.b379333df40cf6b038d6c78d9317a9ff@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * cc: kanetw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 17:03:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 17:03:02 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.653c09a62ab409a413552246ded40cc6@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Old behaviour: {{{ghci}}} omitted printing out {{{()}}} for things of type {{{()}}}. New behaviour: {{{ghci}}}, when passed {{{-no-it}}} (which is the solution to memory leaks) now prints out {{{()}}}. Desired behaviour: Have {{{-no-it}}} not print out {{{()}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 17:28:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 17:28:34 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.636ebe7cb1e692051e0d716e103a1020@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by kanetw): I think I found the reason: win32/OSMem.c {{{ bool osNumaAvailable(void) { return osNumaNodes() > 1; } uint32_t osNumaNodes(void) { /* Cache the amount of NUMA values. */ static ULONG numNumaNodes = 0; /* Cache the amount of NUMA nodes. */ if (!numNumaNodes && !GetNumaHighestNodeNumber(&numNumaNodes)) { numNumaNodes = 1; } return numNumaNodes; } }}} Looks like a off by one. GetNumaHighestNodeNumber is 0 on non-NUMA systems, and >0 on NUMA systems, but osNumaAvailable() checks for >1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 17:30:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 17:30:22 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.9cd48b4a5aff2ae8c2fca84a48a08c6e@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by kanetw): Also note that docs for GetNumaHighestNodeNumber state: "The number of the highest node is not guaranteed to be the total number of nodes." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 17:41:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 17:41:55 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.b8cd63de69433b8f7de9b6f303c8a4a3@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by tdammers): Unfortunately, the `isReflCo` approach does not make a difference. Which suggests that the cases for which the type equality check avoids bad things are not the trivial ones that `isReflCo` can find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:19:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:19:03 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs Message-ID: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data P a = P data T1 a where MkT1 :: forall a. P a -> T1 a MkT2 :: forall a. P a -> T1 (a,a) MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a MkT4 :: forall a b. P a -> P b -> T1 a MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a }}} I can write this function {{{ foo :: T1 (Int, Int) -> () foo (MkT1 (P::P (Int,Int))) = () foo (MkT2 (P::P x)) = (() :: x ~ Int => ()) foo (MkT3 P (P::P Int)) = () foo (MkT4 P (P::P b)) = () foo (MkT5 P (P::P b) (P::P b)) = () }}} but this these two equations fail {{{ foo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ()) foo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ()) }}} I am especially surprised by the second one, given that the very similar equation with `MkT2` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:31:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:31:37 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.548ee4eab974f219120a6a535b889168@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ryan mentions {{{#!hs newtype XMLGenT m a = XMLGenT (m a) deriving (MonadRWS r w s)` }}} I suspect what we want to do is collect the fundeps from the ''superclass constraints'' of `MonadRWS` before doing anything much else. I have the feeling (maybe wrong?) that we can get these more safely than we can fundeps of instance constraints. These should (at least in this case) be sufficient to satisfy the coverage condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:31:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:31:59 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.7770ce2dc2cff4a906b4e9e456db4125@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: FunDeps, Resolution: | deriving 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:35:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:35:27 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.78426d5c86c03da11b7bcc84075dacec@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:39:48 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.b35ef13a0fcad3f2521de12814521892@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.8" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:40:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:40:04 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.e6330aad92863969d36d55135dbc8662@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.10" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:45:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:45:33 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.bec137bda18483c372f8b80c4760356d@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.8" added. ghc -O -dshow-passes -fforce-recomp -fcontext-stack=400 Main.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:45:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:45:33 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.8" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:45:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:45:59 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.2099d3f0442add4f7bf1fb1975274220@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.10" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:45:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:45:59 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.10" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:46:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:46:22 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.1c8d045eda99399f6a293acc505f65cf@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-8.0" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:46:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:46:40 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.098a2ee0a0c21348052b23b0c23774fd@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-8.2" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:46:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:46:56 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.70cd32cc91bc768bc18d69ae7b82be26@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-8.4" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:48:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:48:35 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.6e2e39fb14995e6a1278b8a9dd097b50@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "passes-7.8-redacted" added. 7.8 passes with CPSZ lines removed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 18:55:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 18:55:22 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.8feb262f6ba97f10098242f87d897bcd@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): Thanks osa1 for reproducing this with just ghc and for the analysis. I'll try to poke around over the next few days to see if I can minimize failing case further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:05:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:05:48 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.e651053d9da5447091f69150a2aa2261@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm going to attach `-v` results too, so we can look at how many simplifier passes were used. Is there a way to find out when the simplifier bailed out without a debug build? I don't really know how to get a debug build of 7.8. Building 7.8 with 7.8 didn't work, and I don't have 7.6 lying around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:11:21 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.cb710f718027c3f34e8c21f7b540524a@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a consequence of the fact that a scoped type variable must be a variable, never a type. Another way of saying this is that a type variable brought into scope in a pattern type annotation simply names an existing type variable; it can't, say, bind a type variable to a type. Of course, with type equalities (and therefore GADTs), you can have a type variable `a` and the constraint `a ~ Int`. In this case, you ''can'' bind a scoped type variable to `a`, despite the equality constraint saying that you're essentially binding a scoped type variable to a type. I've personally never liked this design choice around scoped type variables, believing that a pattern-bound type variable should be able to be bound to any type. The lack of ability to do this has actually been a pain point in `singletons` from the beginning, and these examples show that the current behavior isn't even truly self-consistent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:18:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:18:51 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.32ade97e0c993ac6024371495055d06c@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another layer of inconsistency can be found between values and types. GHC accepts this: {{{#!hs data T a where MkT :: Bool -> T Bool f :: T a -> a f (MkT (y :: z)) = y }}} But not this: {{{#!hs type family F (t :: T a) :: a where F (MkT (y :: z)) = y }}} {{{ • Expected kind ‘Bool’, but ‘(y :: z)’ has kind ‘z’ • In the first argument of ‘MkT’, namely ‘(y :: z)’ In the first argument of ‘F’, namely ‘(MkT (y :: z))’ In the type family declaration for ‘F’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:26:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:26:06 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.d4a492447fb8dc8f8d04e225c5738af9@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think comment:3 is a red herring. You're right that GHC rejects that type family, but that has more to do with the way that GHC does type-level GADT pattern matching than anything with scoped type variables. You could argue that it's suboptimal (though it matches what Agda does, I believe), but it's a separate matter from this ticket, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:37:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:37:15 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows Message-ID: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> #15051: -split-objs generates excessively many files on Windows --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- A BuildFlavour = perf build generated ~18k .S files for ghc- prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 19:37:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 19:37:25 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.29a1786bffc0b8d357332acef3ec4f6b@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by kanetw): * version: 8.2.2 => 8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 20:50:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 20:50:05 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.36e1f8a1aaeffc562640a5db7264398d@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > This is a consequence of the fact that a scoped type variable must be a variable, never a type. Another way of saying this is that a type variable brought into scope in a pattern type annotation simply names an existing type variable; it can't, say, bind a type variable to a type. TBH, I don’t understand that part of the docs for `ScopedTypeVariables`. What does it mean for a type variable to be a type variable? Is there a global set of variables in existing? Is it referring to the variables in the signature of of the constructor? … I guess the latter could be, but I agree with your sentiment that that is pretty odd and unsatisfying, especially given the type variables in the type signature of the constructor are not in scope here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 22:02:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 22:02:20 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.c9c5edae2b891b923cb930ec63bae619@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. Sounds plausible. Doesn't sound hard. Can anyone offer a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 22:14:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 22:14:36 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.4cfc8a3113035cdd62afacdf388e3cc8@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What does it mean for a type variable to be a type variable? Imagine the fully-typechecked Core program. Now, does the source-level type variable name a type variable, or some other non-type-variable type? Example: {{{ data T a = MkT a f1 :: T b -> Int f1 (MkT (x::z)) = ... -- OK f2 :: T Boll -> Int f2 (MkT (x::z)) = ... -- Not OK }}} In `f1` the source-level lexical type variable `z` names a type variable in Core. The elaborated version of `f1` could be {{{ f1 = /\b. \(x::T b). case x of { MkT (x::b) -> ... } }}} So `z` names `b`. In `f2`, you'll see that `z` names `Int`. I agree this is a questionable choice. At the time I was worried that it'd be confusing to have a type variable that was just an alias for `Int`; that is not a type variable at all. But in these days of GADTs and type equalities we are all used to that. We'd make a different choice today. Feel free to make a GHC proposal to change this behaviour. It'd be backward compatible! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 23:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 23:14:08 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.a50c24fde73e93b9fde86cd61175dd29@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by simonpj): OK, well commit the patch, and let's investigate the regressions. The places I'd start would be (distinct alternatives) * Try a `cheapEqType`, so we get something in between `isReflCo` (dirt cheap) and `isReflexiveCo` (which uses `eqType`, can be expensive). * Take a regression and see what the (presumably) bigger coercion look like. Then we can see if there's an easy way to kill them off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 17 23:28:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Apr 2018 23:28:53 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.80d840c518ad6d5dad33c39a468caf4a@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 simonpj): > As currently designed, however, TyPrec doesn't fit neatly into this PprPrec paradigm Yes it does! The Note says that currently `FunPrec` and `TyOpPrec` are treated as equal. So we could say {{{ funPrec = Prec 2 tyOpPrec = Prec 2 }}} We have two names so that we can later give them different precedence if we want. As the note says {{{ But the two are different constructors of TyPrec so we could make (->) bind more or less tightly if we wanted. }}} Seems a neat fit to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 00:00:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 00:00:34 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints Message-ID: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 presence of `TypeError`, one can derive instances with `DeriveAnyClass` that would be rejected otherwise. A simplistic example would be: {{{#!haskell {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) class TypeError ('Text "BOOM") => C a where f :: a -> () f _ = () data T = T deriving(C) }}} Of course, any attempt to use the instance leads to a type-error. However, the instance is rejected right away using a normal instance declaration or StandaloneDeriving. While this is a toy example, it can actually happen when using `Generics` and default-signatures, where one would puts a `TypeError` in an instance head for one of the `Generics` constructors to give a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 02:33:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 02:33:05 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.c555d1229a67e79b3119389a9d7da3a3@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Imagine the fully-typechecked Core program. That’s an unsatisfying way to explain a Haskell feature :-) > Feel free to make a GHC proposal to change this behaviour. It'd be backward compatible! Is there someone who is confident about type-checker features that feels inspired to turn this into a proposal? (Richard? :-)) I still feel mostly like a clueless user with a too strong sense of entitlement… But I can give it a shot, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 02:35:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 02:35:37 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.7b0281cab56fa673a750f6019434a624@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've got enough proposals in the air right now. :) So I'll pass the buck: Ryan? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 03:03:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 03:03:11 -0000 Subject: [GHC] #5142: stub header files don't work with the MS C compiler In-Reply-To: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> References: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> Message-ID: <062.ed3dff3e615bc6e071b3fd338645d324@haskell.org> #5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.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 Azel): I'd like to have a go at this issue, is anyone working on it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 09:28:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 09:28:30 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.3ea742ed431392d57110497f7ea612f6@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Nope. I have a personal policy that I never make a GHC proposal unless I understand how it would be implemented in GHC and would be willing to implement it myself, and I don't meet these criteria. Nor am I particularly eager to dive into this part of the codebase—typechecking scoped type variables is black magic, and I'm content to let the experts handle it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 10:39:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 10:39:05 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.7840b6dcb3651ebfc1a996771ff6d614@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): You say that the equivalent instance is "rejected right away using a normal instance declaration or StandaloneDeriving", but I can't reproduce this behavior. In fact, these three equivalent instances all typecheck: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) class TypeError ('Text "BOOM") => C a where f :: a -> () f _ = () data T1 = T1 deriving C data T2 = T2 instance TypeError ('Text "BOOM") => C T2 data T3 = T3 deriving instance TypeError ('Text "BOOM") => C T3 }}} Am I missing something here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 10:59:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 10:59:15 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.4756b1e6dfdde1c5596b0184c490c01a@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): Oh, right you are. I thought that there was code in GHC that was //distinguishing// `FunPrec` from `TyOpPrec`, but after a quick audit, that does not appear to be the case. (Which leaves me a bit baffled that we didn't just define `funPrec = TyOpPrec` and avoided the need for such bizarre `Eq`/`Ord` instances. Oh well.) In that case, this should present a nice opportunity for some code cleanup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 10:59:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 10:59:36 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.1f0c9316db9c0c5cd41f6277420e5218@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): Sorry that I wasn't clear. I meant, using `instance` and `deriving instance` without providing the instance head. {{{#!haskell {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) class TypeError ('Text "BOOM") => C a where f :: a -> () f _ = () data T1 = T1 deriving C data T2 = T2 instance C T2 -- won't typecheck data T3 = T3 deriving instance C T3 -- won't typecheck }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 11:01:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 11:01:00 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.9d66759afc62e09fe7f77265cae53f2c@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Right—that's because what you've written isn't equivalent to what `deriving C` will give you. `deriving C` gives you: {{{#!hs instance TypeError ('Text "BOOM") => C T }}} So I'm quite unclear on what the "bug" is here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 11:07:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 11:07:00 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.f89bc9e84bdca0b4f86be9173123747c@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): Fair enough. I tried to produce a simplified example of the behaviour I'm seeing and went too far. I will add a more relastic example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 12:07:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 12:07:40 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.7ab33ecc68769394942f783b3b8a66e6@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): I can reproduce the problem using servant-generic. A minimal example to reproduce: {{{#!hs #!/usr/bin/env nix-shell #!nix-shell -i "runghc --ghc-arg=-fprint-expanded-synonyms" -p "haskellPackages.ghcWithPackages (pkgs: with pkgs; [servant-server servant-auth-server servant-generic])" {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DeriveGeneric #-} module ApiType where import Data.Text import GHC.Generics import Servant import Servant.Auth.Server import Servant.API import Servant.Generic type Get302 (cts :: [*]) (hs :: [*]) = Verb 'GET 302 cts (Headers (Header "Location" String ': hs) NoContent) type API = ToServant (GenericAPI AsApi) data GenericAPI route = GenericAPI { root :: route :- Get302 '[JSON] '[ Header "Set-Cookie" SetCookie] } deriving Generic server :: Server API server = toServant endpoints endpoints :: GenericAPI AsServer endpoints = GenericAPI { root = handler } handler :: Handler (Headers '[ Header "Location" Text , Header "Set-Cookie" SetCookie] NoContent) handler = undefined main :: IO () main = undefined }}} Yields: {{{ ghc15043.hs:33:12: error: • Couldn't match type ‘Text’ with ‘[Char]’ Expected type: AsServer :- Get302 '[JSON] '[Header "Set-Cookie" SetCookie] Actual type: Handler (Headers '[Header "Location" Text, Header "Set-Cookie" SetCookie] NoContent) • In the ‘root’ field of a record In the expression: GenericAPI {root = handler} In an equation for ‘endpoints’: endpoints = GenericAPI {root = handler} | 33 | { root = handler | ^^^^^^^ }}} Note that without using servant-generic, I do get type synonyms expanded, although it's not particulary helpful in this case: {{{ works-ghc15043.hs:24:10: error: • Couldn't match type ‘Text’ with ‘[Char]’ Expected type: Server API Actual type: Handler (Headers '[Header "Location" Text, Header "Set-Cookie" SetCookie] NoContent) Type synonyms expanded: Expected type: ServerT API Handler Actual type: Handler (Headers '[Header "Location" Text, Header "Set-Cookie" SetCookie] NoContent) • In the expression: handler In an equation for ‘server’: server = handler | 24 | server = handler | ^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 12:16:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 12:16:59 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.89fd1871fb420126918ff038782a3772@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 12:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 12:22:35 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.b975b77df5255f93bcf77d159b8c234a@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): Ok, here is a better example. Class `C` should have a default implementation for every generic type that is not a sum. Instead of omitting the instance for `:+:`, I use a `TypeError` in the head of the instance for `:+:` to provide a more clear error message. {{{#!haskell {-# LANGUAGE DataKinds #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeOperators #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) import qualified GHC.Generics as Gen class C a where f :: a -> () default f :: (Gen.Generic a, GC (Gen.Rep a)) => a -> () f = gf . Gen.from class GC b where gf :: b x -> () instance GC x => GC (Gen.M1 i c x) where gf (Gen.M1 x) = gf x instance GC Gen.V1 where gf _ = () instance GC Gen.U1 where gf _ = () instance GC (Gen.K1 i t) where gf _ = () instance GC (l Gen.:*: r) where gf _ = () instance TypeError ('Text "Can't derive C for sums") => GC (l Gen.:+: r) where gf _ = error "unreachable" data TV deriving (Gen.Generic, C) data TU = TU deriving (Gen.Generic, C) data TK = TK Int deriving (Gen.Generic, C) data TP = TP Int Int deriving (Gen.Generic, C) data TS = TSL | TSR deriving (Gen.Generic, C) -- should reject right away }}} This program is accepted, but any attempt to use the instance will fail at compile time. I find this surprising and less useful than rejecting the program right away. If one instead uses one of: {{{#!haskell instance C TS -- or deriving instance C TS }}} the program is rejected (with the intended error message). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 12:45:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 12:45:09 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.95025afe8a7cad888fc7e0baf1bd2d2d@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors 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: => CustomTypeErrors Comment: Ah. You're arguing something different, then. You're proposing that if you have a type class instance with `TypeError` in the context (such as the three instances in comment:1), then GHC should reject that instance itself, instead of rejecting //uses// of that instance. This would be a pretty big breaking change. There is a lot of code out there which relies on the ability to use `TypeError` constraints in instance contexts. (For examples see the [http://git.haskell.org/ghc.git/blob/5d76846405240c051b00cddcda9d8d02c880968e:/testsuite/tests/deriving/should_compile/T14339.hs#l16 T14339 test case].) I think if you want to see this behavior be enshrined into GHC, you should first submit a proposal to the [https://github.com /ghc-proposals/ghc-proposals GHC proposals repo], and argue why this behavior is more desirable over the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 13:11:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 13:11:48 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.7415c4871e56e2a37235392dd312f45e@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: osa1 (added) Comment: OK, I believe I can reproduce the essence of this with the following, smaller example: {{{#!hs module Bug where type Foo = Int f :: Maybe Foo f = ['a'] }}} {{{ $ ghci Bug.hs -fprint-expanded-synonyms GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:5: error: • Couldn't match expected type ‘Maybe Foo’ with actual type ‘[Char]’ • In the expression: ['a'] In an equation for ‘f’: f = ['a'] | 6 | f = ['a'] | ^^^^^ }}} Note that this error message does not expand `Foo`. That being said, the GHC commentary would suggest that this is intentional. See [http://git.haskell.org/ghc.git/blob/5d76846405240c051b00cddcda9d8d02c880968e:/compiler/typecheck/TcErrors.hs#l2431 this Note]: {{{#!hs {- Note [Expanding type synonyms to make types similar] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In type error messages, if -fprint-expanded-types is used, we want to expand type synonyms to make expected and found types as similar as possible, but we shouldn't expand types too much to make type messages even more verbose and harder to understand. The whole point here is to make the difference in expected and found types clearer. `expandSynonymsToMatch` does this, it takes two types, and expands type synonyms only as much as necessary. Given two types t1 and t2: * If they're already same, it just returns the types. * If they're in form `C1 t1_1 .. t1_n` and `C2 t2_1 .. t2_m` (C1 and C2 are type constructors), it expands C1 and C2 if they're different type synonyms. Then it recursively does the same thing on expanded types. If C1 and C2 are same, then it applies the same procedure to arguments of C1 and arguments of C2 to make them as similar as possible. Most important thing here is to keep number of synonym expansions at minimum. For example, if t1 is `T (T3, T5, Int)` and t2 is `T (T5, T3, Bool)` where T5 = T4, T4 = T3, ..., T1 = X, it returns `T (T3, T3, Int)` and `T (T3, T3, Bool)`. * Otherwise types don't have same shapes and so the difference is clearly visible. It doesn't do any expansions and show these types. Note that we only expand top-layer type synonyms. Only when top-layer constructors are the same we start expanding inner type synonyms. -} }}} Since the "top-level constructors" in this example, `Maybe` and `[]`, are different, it avoids expanding the type synonyms in their arguments. The same reason applies to your example, since the "top-level constructors" are `(:-)` and `Handler`, which are different. osa1, you implemented `-fprint-expanded-synonyms` in ae96c751c869813ab95e712f8daac8516bb4795f. Do you agree with this analysis? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 13:35:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 13:35:10 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.41ae60a14cd608d7db00e2771423c254@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): Although I don't know enough to judge the conclusion in the comment, it seems like it's a zero sum game unless there's a way to tweak level/verbosity of expansion or be able to interactively dig in. Thanks for helping me figure this one out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 14:18:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 14:18:29 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.95999aaef0957f3fc0dcb1d61978e6bb@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): I'm not sure I see why this would be a breaking change. In this last example (which is the important one, the original was an oversimplification, we can disregard it), why would these two be any different: {{{#!haskell data TS = TSL | TSR deriving (Gen.Generic, C) }}} vs {{{#!haskell data TS = TSL | TSR deriving (Gen.Generic) instance C TS }}} The latter fails, IIUC, because we are trying to see if the default signature of `f` in `C` applies to `TS`, and this forces the reduction of `GC (Rep TS)`, that eventually leads to the `TypeError`. This is the standard behaviour. Am I mistaken in thinking that these two declarations should be equivalent? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 15:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 15:24:21 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.6c6d64c7242e2843f23f2271ce4d0e42@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: 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): Here is the difference between these two programs. In the first one: {{{#!hs data TS = TSL | TSR deriving (Gen.Generic, C) }}} You are requesting that GHC come up with the `???` in the following instance: {{{#!hs instance ??? => C TS }}} Because `C` has a superclass constraint, `TypeError (...)`, it infers that for `???`. If you had picked different superclass constraints for `C`, such as `class (Eq a, Show a) => C a`, then GHC would have inferred `(Eq a, Show a)` for `???`. In the second example, you are putting the task of coming up with the context in your own hands. You have boldly declared that the instance context should be `()`! As a result, GHC tries to unify `TypeError (...)` with `()`, which causes the type error to trigger. Boom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 15:26:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 15:26:41 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.d94275a7bba0c37ac674c5c81c5dbe62@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer 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 ckoparkar): I made a stupid assumption that `getArgs` resides in `process`. But that's actually exported by `System.Environment`. Moving this to `base` (`GHC.ResponseFile`), and then perhaps adding a `getArgsWithResponseFile` function to `System.Environment` sounds like a good idea. I'll start working on the patch today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 15:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 15:34:59 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.8d5959c1cbbceef448615e78b97c254c@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): RyanGlScott, your analysis is correct, this is by design. It's impossible to provide one flag that'll make everyone happy, because expanding _all_ synonyms (as noted in the note quoted in comment:5) often results in huge types that are impossible to compare -- that's why we choose to expand until the difference becomes apparent. So perhaps we can provide another flag for expanding _all_ synonyms when needed (although I'm not sure if that'd result in reasonably-sized types in this case -- servant's types are quite complex!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 15:36:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 15:36:08 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.729662fa6851c14a7efbd6667c966c11@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): Let's forget about the program in comment:1, I understand what GHC is doing there and I agree it is the expected behaviour. :) The issue is only shown in the program of comment:5. In this program ** `C` has an empty context**, so writing {{{#!haskell data TS = TSL | TSR deriving (Gen.Generic, C) }}} and writing {{{#!haskell data TS = TSL | TSR deriving (Gen.Generic) instance C TS }}} should have the same result, but it doesn't. The first form is accepted, the second one is rejected (as expected). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 16:01:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 16:01:18 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.485f0d50d5357474c2853459e80cbbee@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: 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): When `deriving` infers an instance context, it collects some set of constraints, simplifies them as much as possible (discharging constraints when possible), and uses the remaining constraints as the context. For instance, in `data T a = MkT a Int deriving Show`, you start with the constraint set `(Show a, Show Int)`. GHC is able to discharge the `Show Int` constraint, since there's a top-level instance for that, but not the `Show a` constraint, so the final instance context is `Show a`. Returning to your `TypeError` example, you start with a constraint set that contains many constraints, with `TypeError (...)` sprinkled among them. There is no way to discharge a `TypeError (...)` constraint—if you could, you would be able to do lots of things you weren't supposed to be able to do, since `TypeError` is designed to be the context for unreachable code! Thus, `TypeError (...)` ends up in the final instance context. At this point, you might be thinking "well why doesn't the constraint solver immediately error when it encounters any constraint mentioning `TypeError`"? That might be feasible, but again, it would be a breaking change—it would explicitly go against the convention established by #14339. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 16:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 16:30:23 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.40ea1297e9101e41e899752266173a21@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3416 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Zemyla): The instance for `(<|>)` would probably be more efficient as: {{{ #!haskell ZipList xs <|> ZipList ys = ZipList $ go (0 :: Int) xs where go n _ | n `seq` False = undefined go n [] = drop n ys go n (x:xs) = x:go (n + 1) xs }}} This way, it only has to iterate over xs once. Or, you could do it in `build`/`foldr` style: {{{ #!haskell ZipList xs <|> ZipList ys = ZipList (build $ zipListPlusBF xs ys) zipListPlusBF :: [a] -> [a] -> (a -> b -> b) -> b -> b zipListPlusBF xs ys c z = foldr goX endX xs 0# where goX x r n# = c x $ r (n# +# 1#) endX n# = foldr goY endY ys n# goY y r n# | isTrue# (n# ># 0#) = r (n# -# 1#) | otherwise = c y $ r 0# endY _ = z }}} This would have the advantage that it should ideally realize, for instance, that pure x <|> anything = pure x, or at the very least doesn't reference the right-hand side at all. We could probably use both and switch between them with `RULES` like is done for most of the algorithms in `Data.List`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 17:16:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 17:16:09 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.ef86cf28b7f2644d60070cbe1bb136fd@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): I don't disagree with anything you are saying. The issue is that `deriving` is behaving differently from `instance` and from `deriving instance`. Consider this hopefully more clear example: {{{#!haskell {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} module T2 where import Data.Kind(Constraint) import GHC.TypeLits(TypeError, ErrorMessage(..)) class D a where f :: a default f :: DeferError a => a f = error "unreachable" type family DeferError a :: Constraint where DeferError a = TypeError ('Text "Boom") data X deriving D -- < -- ACCEPTED data Y instance D Y -- < -- REJECTED data Z deriving instance D Z -- < -- REJECTED }}} Do you aggree that either the three instances should be accepted here or the three instances should be rejected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 17:20:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 17:20:07 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.e723b9be13f06364783d92b398224048@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: 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): You've only presented me with the options that all three should be accepted, or all three should be rejected. I don't agree with either of those options. I think that, given the current established conventions for how `TypeError` works, the first option should be accepted, and the latter two options should be rejected. The first option is working in a fundamentally different way than the latter two, so it's foolhardy to try and equate them. I think there might be a different semantics for `TypeError` which would reject the first option. But I'd like to put an emphasis on "different". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 18:21:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 18:21:02 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.4cdb5bbe45cc58f212fede4a0fafa627@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jcpetruzza): Ok, I think I understand your point: what we see follows from the documented behaviour for `DerivingAnyClass` so there is really no bug here. Tbh, I hadn't noticed until right now that `deriving` would propagate constraints coming from the default signatures! The initial example in the docs says: > {{{#!haskell > data Foo = Foo deriving (Show, SPretty) > }}} > > The above code is equivalent to: > > {{{#!haskell > data Foo = Foo deriving Show > instance SPretty Foo > }}} and somehow the idea that `deriving` would declare the instance over an empty context got stuck in my head for a long time. Hence my insistance in expecting the results to be the same! (maybe `Foo a` would make for a better example there?) In any case, I agree that `deriving` is doing the right thing here. It is a bit unfortunate since I'm not sure I want to use `TypeError` as it is for generic default methods then, but on the other hand, without it error messages can be a screenful! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 18:21:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 18:21:53 -0000 Subject: [GHC] #15052: DeriveAnyClass instances may skip TypeError constraints In-Reply-To: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> References: <049.785858b7bc6e424b1027ada67d5366c6@haskell.org> Message-ID: <064.fab2365164cd59df2e5b023a1eaa647b@haskell.org> #15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: | CustomTypeErrors 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 jcpetruzza): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 20:26:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 20:26:07 -0000 Subject: [GHC] #14689: Load order of .ghci config files is counterintuitive In-Reply-To: <050.b87151fcae6e630e6dfb4d15d5b0bf91@haskell.org> References: <050.b87151fcae6e630e6dfb4d15d5b0bf91@haskell.org> Message-ID: <065.5d4000e9efc26863917537681a5e174e@haskell.org> #14689: Load order of .ghci config files is counterintuitive -------------------------------------+------------------------------------- Reporter: hal9zillion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: #14250, #6017 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Funny thing is, it was raised as a [GHC proposal](https://github.com/ghc- proposals/ghc-proposals/pull/123) and was then told it might work better as a ticket :). I would love to see this fixed, regardless of which process is used to fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 21:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 21:17:16 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) Message-ID: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | 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 minimal example causes a compiler panic. {{{ {-# OPTIONS_GHC -O1 } " #-} }}} {{{ ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180413 for x86_64-unknown-mingw32): getOptions'.parseToks: Couldn't read "\r\n\"\r\n " as String Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happens in HEAD and 8.2.2 at least. Double quotes seem to confuse the parser. Also panics if there are two doublequotes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 23:03:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 23:03:35 -0000 Subject: [GHC] #15020: PatternSynonyms: Problems with quantified constraints / foralls In-Reply-To: <051.dc34120fba728e1a69cd66ce48b598e6@haskell.org> References: <051.dc34120fba728e1a69cd66ce48b598e6@haskell.org> Message-ID: <066.12392254a45a372d6d7d1d12436efb4f@haskell.org> #15020: PatternSynonyms: Problems with quantified constraints / foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Would you expect the following to work? {{{ data Lam2 a = Lam2 (forall mm. Monad mm => mm a) | Other newtype Forall f = Forall (forall xx. f xx) mLam2 :: Forall Lam2 -> r -> ((forall xx mm. Monad mm => mm xx) -> r) -> r mLam2 (Forall (Lam2 lam)) d k = k lam mLam2 (Forall Other) d k = d }}} Here `mLam2` is the sort of matching function that GHC builds for `PLam2`. And indeed `mLam2` is rejected because `lam` is not polymorphic enough. Is that so unreasonable? (I checked why `mkLam3` works; it's because teh pattern matching is pushed into the argument of the continuation, something like this {{{ mLam3 :: Forall Lam2 -> r -> ((forall xx mm. Monad mm => mm xx) -> r) -> r mLam3 x d k = k (case x of { Forall (Lam2 lam) -> lam }) }}} But this won't work when we want to bind multiple arguments, or when the match can fail.) I don't see an easy way to improve this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 18 23:18:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Apr 2018 23:18:17 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.6ee2d4a8b9df1e6da5064be92ef29502@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 jship): We have worked around this issue by following in the Nix folks' footsteps and using a wrapper script around `ld` to recursively subdivide the dependencies into a tree of re-exporting delegate libraries. The script, an example using aosivitz repro, and more info about this issue is available here: https://github.com/Simspace/ld-wrapper-macos The example in the repo shows how the wrapper script can be used to successfully build a project with 750 direct dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 01:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 01:36:41 -0000 Subject: [GHC] #14689: Load order of .ghci config files is counterintuitive In-Reply-To: <050.b87151fcae6e630e6dfb4d15d5b0bf91@haskell.org> References: <050.b87151fcae6e630e6dfb4d15d5b0bf91@haskell.org> Message-ID: <065.2b5b28c83b77ddecb8ed0776ea881d26@haskell.org> #14689: Load order of .ghci config files is counterintuitive -------------------------------------+------------------------------------- Reporter: hal9zillion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: #14250, #6017 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > OTOH there are a couple of open issues where people dont like the idea of local ghci evaluation for security reasons Thanks for paying attention to these requests, but I think your proposal is mostly orthogonal to these concerns, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 07:24:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 07:24:45 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI Message-ID: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After playing with vectors in ghci I got following error: {{{ ghc: internal error: Unable to commit 1048576 bytes of memory }}} It happened randomly, on empty prompt while no query was being evaluated I am using latest version of GHC on Arch Linux Here is my whole session: {{{ >λ= import Criterion Criterion Criterion.IO.Printf Criterion.Main.Options Criterion.Report Criterion.Analysis Criterion.Internal Criterion.Measurement Criterion.Types Criterion.IO Criterion.Main Criterion.Monad >λ= import Criterion.Main >λ= import Data.Vector >λ= import Data.Vector as V >λ= main = default defaultConfig defaultMain defaultMainWith >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999] benchmarking TESTXD time 19.81 μs (19.66 μs .. 19.99 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 13.47 μs (12.93 μs .. 14.11 μs) std dev 853.8 ns (542.7 ns .. 1.249 μs) variance introduced by outliers: 65% (severely inflated) >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999] benchmarking TESTXD time 19.62 μs (19.39 μs .. 19.99 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 13.49 μs (12.85 μs .. 14.51 μs) std dev 1.154 μs (524.9 ns .. 1.704 μs) variance introduced by outliers: 77% (severely inflated) >λ= v = V.fromList [1..100000] Display all 192 possibilities? (y or n) V.! V.fold1M' V.indexed V.prescanl V.unsafeDrop V.!? V.fold1M'_ V.init V.prescanl' V.unsafeFreeze V.++ V.fold1M_ V.iscanl V.prescanr V.unsafeHead V.// V.foldM V.iscanl' V.prescanr' V.unsafeHeadM V.MVector V.foldM' V.iscanr V.product V.unsafeIndex V.Vector V.foldM'_ V.iscanr' V.replicate V.unsafeIndexM V.accum V.foldM_ V.iterateN V.replicateM V.unsafeInit V.accumulate V.foldl V.iterateNM V.reverse V.unsafeLast V.accumulate_ V.foldl' V.izipWith V.scanl V.unsafeLastM V.all V.foldl1 V.izipWith3 V.scanl' V.unsafeSlice V.and V.foldl1' V.izipWith4 V.scanl1 V.unsafeTail V.any V.foldr V.izipWith5 V.scanl1' V.unsafeTake V.backpermute V.foldr' V.izipWith6 V.scanr V.unsafeThaw V.break V.foldr1 V.izipWithM V.scanr' V.unsafeUpd V.concat V.foldr1' V.izipWithM_ V.scanr1 V.unsafeUpdate V.concatMap V.forM V.last V.scanr1' V.unsafeUpdate_ V.cons V.forM_ V.lastM V.sequence V.unstablePartition V.constructN V.force V.length V.sequence_ V.unzip V.constructrN V.freeze V.map V.singleton V.unzip3 V.convert V.fromList V.mapM V.slice V.unzip4 V.copy V.fromListN V.mapM_ V.snoc V.unzip5 V.create V.generate V.mapMaybe V.span V.unzip6 V.createT V.generateM V.maxIndex V.splitAt V.update V.drop V.head V.maxIndexBy V.sum V.update_ V.dropWhile V.headM V.maximum V.tail V.zip V.elem V.ifilter V.maximumBy V.take V.zip3 V.elemIndex V.ifoldM V.minIndex V.takeWhile V.zip4 V.elemIndices V.ifoldM' V.minIndexBy V.thaw V.zip5 V.empty V.ifoldM'_ V.minimum V.toList V.zip6 V.enumFromN V.ifoldM_ V.minimumBy V.unfoldr V.zipWith V.enumFromStepN V.ifoldl V.modify V.unfoldrM V.zipWith3 V.enumFromThenTo V.ifoldl' V.notElem V.unfoldrN V.zipWith4 V.enumFromTo V.ifoldr V.null V.unfoldrNM V.zipWith5 V.filter V.ifoldr' V.or V.uniq V.zipWith6 V.filterM V.imap V.partition V.unsafeAccum V.zipWithM V.find V.imapM V.postscanl V.unsafeAccumulate V.zipWithM_ V.findIndex V.imapM_ V.postscanl' V.unsafeAccumulate_ V.findIndices V.imapMaybe V.postscanr V.unsafeBackpermute V.fold1M V.indexM V.postscanr' V.unsafeCopy >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x)] :8:93: error: parse error (possibly incorrect indentation or mismatched brackets) ] λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x) :9:74: error: • Couldn't match expected type ‘Benchmarkable’ with actual type ‘Int -> Benchmarkable’ • Probable cause: ‘whnf’ is applied to too few arguments In the second argument of ‘($)’, namely ‘whnf (\ x -> (!) v x)’ In the expression: bench "TESTV" $ whnf (\ x -> (!) v x) In the first argument of ‘defaultMain’, namely ‘[bench "TESTXD" $ whnf ([1 .. 100000] !!) 9999, >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x) 9999] benchmarking TESTXD time 20.61 μs (20.47 μs .. 20.80 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 14.41 μs (13.85 μs .. 14.88 μs) std dev 805.2 ns (588.3 ns .. 1.036 μs) variance introduced by outliers: 59% (severely inflated) benchmarking TESTV time 1.796 ms (1.768 ms .. 1.831 ms) 0.997 R² (0.995 R² .. 0.999 R²) mean 1.426 ms (1.367 ms .. 1.481 ms) std dev 153.6 μs (123.2 μs .. 190.1 μs) variance introduced by outliers: 69% (severely inflated) (V.!) >λ= >λ= (V.!) v 999 1000 >λ= (V.!) v 9999 10000 >λ= l = [1..100000]) :13:16: error: parse error on input ‘)’ >λ= l = [1..100000] >λ= l !! 9999 10000 >λ= l !! 99999 100000 >λ= l !! 999999 *** Exception: Prelude.!!: index too large >λ= l = [1..10000000] >λ= l !! 999999 1000000 >λ= l !! 9999999 10000000 >λ= l !! 99999999 *** Exception: Prelude.!!: index too large >λ= sum l :22:1: error: Ambiguous occurrence ‘sum’ It could refer to either ‘Data.Vector.sum’, imported from ‘Data.Vector’ or ‘Prelude.sum’, imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’) >λ= Prelude.sum l 50000005000000 >λ= Prelude.sum l 50000005000000 >λ= v = V.fr V.freeze V.fromList V.fromListN >λ= v = V.fromList l >λ= V.last v 10000000 >λ= :sprint v v = _ Display all 1088 possibilities? (y or n) >λ= V.sum v 50000005000000 >λ= V.sum v 50000005000000 >λ= V.last v 10000000 >λ= relast l read readIO readLn reads realToFrac rem replicate return readFile readList readParen readsPrec recip repeat replicateM reverse >λ= Prelude.last l 10000000 >λ= Prelude.last l 10000000 >λ= V.last v 10000000 >λ= :t (//) (//) :: Vector a -> [(Int, a)] -> Vector a >λ= :t v v :: (Enum a, Num a) => Vector a >λ= l = [1..10000000] :: [Int] >λ= last l :37:1: error: Ambiguous occurrence ‘last’ It could refer to either ‘Data.Vector.last’, imported from ‘Data.Vector’ or ‘Prelude.last’, imported from ‘Prelude’ (and originally defined in ‘GHC.List’) >λ= import Prelude as P >λ= P.last l 10000000 >λ= v = from fromEnum fromInteger fromIntegral fromList fromListN fromRational >λ= v = fromList l >λ= :t v v :: Vector Int >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= v = fromList l >λ= P.last l 10000000 >λ= P.last l 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= P.last l 10000000 >λ= P.last l 10000000 >λ= l = [1..100000000] :: [Int] >λ= v = fromList l >λ= P.last l 100000000 >λ= V.last v 100000000 >λ= V.last v 100000000 >λ= :t v v :: Vector Int >λ= :t v v :: Vector Int >λ= :sprint v v = Data.Vector.Vector 0 100000000 _ >λ= ghc: internal error: Unable to commit 1048576 bytes of memory (GHC version 8.2.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 12349 killed stack ghci }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 08:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 08:01:23 -0000 Subject: [GHC] #14997: mut_list_size calculation is off In-Reply-To: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> References: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> Message-ID: <058.97a9a939e7bde006bf88517d3d7614c4@haskell.org> #14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: 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: Jaffacake (removed) * cc: simonmar (added) Comment: Replying to [comment:1 bgamari]: > Cc: Jaffacake added; simonmar removed Why?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 08:02:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 08:02:55 -0000 Subject: [GHC] #14997: mut_list_size calculation is off In-Reply-To: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> References: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> Message-ID: <058.ca08a331de8c43e08dbcb27309fd8329@haskell.org> #14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I imagine there's a bug in this debug output. It hasn't been used for a long time as far as I recall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 08:03:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 08:03:54 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package Message-ID: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- A user boldly types: {{{ > import Data.Foo : error: Could not find module ‘Data.Foo’ It is a member of the hidden package ‘package-foo-0.1.0.0 at package- foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’. }}} The above error message is rather useless for a newcomer to ghci. After lots of googling, the user figures that `:set -v -package package-foo` seems to solve it. The original error should be: {{{ > import Data.Foo : error: Could not find module ‘Data.Foo’ It is a member of the hidden package ‘package-foo-0.1.0.0 at package- foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’. Try :set -package package-foo to make it visible. }}} Or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 08:18:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 08:18:51 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.47c2c7bc1a5009d39003f108e8679b99@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: patch Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 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): phab:D4606 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => phab:D4606 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 09:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 09:55:24 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.3bd17f751239bf39bf1c27005f198d5a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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): > My existing patch still panics on this case, but I agree that no one should spend time on this until that patch lands. Richard, now that the patch has landed, and this stuff is in your head, might you look at this? I doubt it's hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 10:24:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 10:24:10 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.77e68107ee10ac3ea5ef39fd825cead3@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes strong +1, I've been meaning to create this very ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 12:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 12:52:47 -0000 Subject: [GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds In-Reply-To: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> References: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> Message-ID: <065.2c2848b356ea179164b740efa65e0cb4@haskell.org> #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4554 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"447d1264abcd52bdd98267d109bfc1ff1c96ad27/ghc" 447d1264/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="447d1264abcd52bdd98267d109bfc1ff1c96ad27" Fix #14710 with more validity checks during renaming Summary: #14710 revealed two unfortunate regressions related to kind polymorphism that had crept in in recent GHC releases: 1. While GHC was able to catch illegal uses of kind polymorphism (i.e., if `PolyKinds` wasn't enabled) in limited situations, it wasn't able to catch kind polymorphism of the following form: ```lang=haskell f :: forall a. a -> a f x = const x g where g :: Proxy (x :: a) g = Proxy ``` Note that the variable `a` is being used as a kind variable in the type signature of `g`, but GHC happily accepts it, even without the use of `PolyKinds`. 2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC incorrectly accepts the following definition: ```lang=haskell f :: forall k (a :: k). Proxy a f = Proxy ``` Even though `k` is explicitly bound and then later used as a kind variable within the same telescope. This patch fixes these two bugs as follows: 1. Whenever we rename any `HsTyVar`, we check if the following three criteria are met: (a) It's a type variable (b) It's used at the kind level (c) `PolyKinds` is not enabled If so, then we have found an illegal use of kind polymorphism, so throw an error. This check replaces the `checkBadKindBndrs` function, which could only catch illegal uses of kind polymorphism in very limited situations (when the bad kind variable happened to be implicitly quantified in the same type signature). 2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not enabled and either of the following criteria are met: (a) An explicitly bound type variable is used in kind position in the body of a `forall` type. (b) An explicitly bound type variable is used in kind position in the kind of a bound type variable in a `forall` type. `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr Reviewed By: simonpj Subscribers: thomie, carter GHC Trac Issues: #14710 Differential Revision: https://phabricator.haskell.org/D4554 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 12:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 12:52:47 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.6260231f8d2ed03aa503a29fd410660c@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Phab:D4604 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"2fdfe056812ec469a05f46f228ef076942297b5f/ghc" 2fdfe056/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fdfe056812ec469a05f46f228ef076942297b5f" Bump unix submodule to version 2.8.0.0 Summary: Requires bumping several submodules. Test Plan: ./validate Reviewers: hvr, bgamari Subscribers: thomie, carter GHC Trac Issues: #15042 Differential Revision: https://phabricator.haskell.org/D4604 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 12:54:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 12:54:53 -0000 Subject: [GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds In-Reply-To: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> References: <050.c0df5def4de65d7ecd4d01ad9668904c@haskell.org> Message-ID: <065.3962b7ca55786b0750696a00d0eac183@haskell.org> #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: fixed | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | polykinds/T14710 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4554 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => polykinds/T14710 * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.6.1 Comment: It's probably not wise to merge this into 8.4.2, since this technically causes `PolyKinds` to reject more programs than before (even if the programs it was erroneously accepting were only valid for a few GHC releases). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 12:55:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 12:55:34 -0000 Subject: [GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD In-Reply-To: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> References: <050.799924f46ad024742c4f2a26dc466a5e@haskell.org> Message-ID: <065.5921686750c15d0c9231e60598cc6aa6@haskell.org> #15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 15018 Related Tickets: #15018 | Differential Rev(s): Phab:D4604 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 13:04:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 13:04:25 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.29e4209aace41e254e9bc67d69c0ecee@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => debugger -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 13:51:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 13:51:16 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.c1073ae27deb7c798c4f27ac928e62c8@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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 osa1): * keywords: => newcomer Comment: +1 from me as well. Would anyone like to offer a patch? Should be a one line change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 13:57:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 13:57:51 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.75e039d1461fc9a06aae3d9b5eb9dc11@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is a `mmap()` failure. Not sure how to debug as I can't reproduce it on my Ubuntu 16.04 laptop when I run the last few commands that allocates the large vector and evaluates it. It'd be helpful if we could have a reproducer as a ghci script (i.e. a text file with list of GHCi commands that triggers this error). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 14:11:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 14:11:11 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.a6e9ad09de72457b2328696416d281df@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4609 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4609 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 14:54:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 14:54:47 -0000 Subject: [GHC] #15056: Wrappers inlined too late Message-ID: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider these two modules {{{ module Foo where test :: Int -> Bool test 0 = True test n = test (n-1) foo :: Foldable t => Int -> t Int -> Int foo n xs | test n = foldr (+) n xs | otherwise = n+7 }}} and {{{ module Bar where import Foo blam x = f 3 [1..x] }}} If we simply inline `foo` into `blam`, we get `foldr/build` fusion. And that is exactly what happens if you compile `Foo` with `-fno-strictness`. But what actually happens is * When compiling `Foo`, strictness analysis does worker/wrapper for `foo`. * The wrapper currently gets an aciviation of "active only in phase 0"; see `Note [Wrapper activation]` in `WorkWrap`. * So `foo` is ultimately inlined (actually its worker is inlined too) but too late for fusion to take place. This is bad: optimising `Foo` makes the overall runtime increase. I have seen other examples of this. The general pattern is: * Without worker/wrapper, a function `f` may inline, which exposes opportunities for functions in its body to participate in rule rewrites * With worker/wrapper, no inlining happens until phase 0; and that is too late for the rules to fire. Obvious thought: allow wrappers from strictness analysis to inline earlier. I'll try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 15:44:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 15:44:01 -0000 Subject: [GHC] #14944: Compile speed regression In-Reply-To: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> References: <042.a1a810a22d187d8f36f05e0ae090a13a@haskell.org> Message-ID: <057.15bf04c7bc90cca19eee0160c91a9ed0@haskell.org> #14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In 7.8, Main starts compiling like this (from -dshow-passes): {{{ Result size of Desugar (after optimization) = {terms: 3,973, types: 630,023, coercions: 196} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 3,384, types: 628,452, coercions: 5} Result size of Simplifier iteration=2 = {terms: 3,386, types: 628,458, coercions: 5} Result size of Simplifier iteration=3 = {terms: 3,384, types: 628,456, coercions: 5} Result size of Simplifier = {terms: 3,384, types: 628,456, coercions: 5} *** Specialise: Result size of Specialise = {terms: 4,785, types: 865,456, coercions: 5} }}} In 7.10, on the other hand, it starts like this: {{{ Result size of Desugar (after optimization) = {terms: 3,973, types: 630,023, coercions: 196} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 4,362, types: 630,802, coercions: 196} Result size of Simplifier = {terms: 4,362, types: 630,802, coercions: 196} *** Specialise: Result size of Specialise = {terms: 12,088, types: 2,092,764, coercions: 392} }}} So 7.8 immediately tossed a slew of coercions in the first simplifier iteration, and the simplification otherwise kept sizes pretty much the same. In 7.10, we only do one round of simplification, the coercion count doesn't go down, the term count goes up a bit, and then specialization goes wild. No, I don't know what any of this really means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 15:54:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 15:54:07 -0000 Subject: [GHC] #15057: Lint types created by newFamInst Message-ID: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15012, we observed a terrible failure resulting from `newFamInst` creating a type family instance with an unbound type variable on the right-hand side. What's worse, `-dcore-lint` didn't catch it! Let's fix that by calling `lintType` on the types involved in `newFamInst`. A wrinkle in this plan is that `lintType` currently expands all type synonyms, but the offending type in #15012 had the unbound variable occur in a type synonym application, so expanding type synonyms would make this naughtiness seemingly vanish (from Core Lint's perspective). We should configure `lintType` so that one can control its type synonym expansion behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:11:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:11:17 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.3bb16e28f3036ccbe2e7d6b2090ae6fa@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures 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): #15039 I know what is going on here. When we first introduced explicit equalities Richard arranged to make the pretty-printer conceal some of the menagerie, with some ad-hoc rules sketched in `IfaceType`: {{{ Note [Equality predicates in IfaceType] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GHC has several varieties of type equality (see Note [The equality types story] in TysPrim for details). In an effort to avoid confusing users, we suppress the differences during "normal" pretty printing. Specifically we display them like this: Predicate Pretty-printed as Homogeneous case Heterogeneous case ---------------- ----------------- ------------------- (~) eqTyCon ~ N/A (~~) heqTyCon ~ ~~ (~#) eqPrimTyCon ~# ~~ (~R#) eqReprPrimTyCon Coercible Coercible By "homogeneeous case" we mean cases where a hetero-kinded equality (all but the first above) is actually applied to two identical kinds. Unfortunately, determining this from an IfaceType isn't possible since we can't see through type synonyms. Consequently, we need to record whether this particular application is homogeneous in IfaceTyConSort for the purposes of pretty-printing. All this suppresses information. To get the ground truth, use -dppr-debug (see 'print_eqs' in 'ppr_equality'). See Note [The equality types story] in TysPrim. }}} There's a flag to control this: `-fprint-equality-relations`, and using that flag makes both oddities go away. In this particular case, although it displays `Coercible a b`, it is really pretty printing `a ~R# b`! And that is why the kind looks wrong: it's the kind of `a ~R# b`. So concealing the reality is jolly confusing here. Moreover, for reasons I don't understand, `-fprint-explicit-kinds` affects the behhaviour too, hence oddness (2). It's all in `IfaceType.ppr_equality`, which I reproduce below {{{ ppr_equality :: TyPrec -> IfaceTyCon -> [IfaceType] -> Maybe SDoc ppr_equality ctxt_prec tc args | hetero_eq_tc , [k1, k2, t1, t2] <- args = Just $ print_equality (k1, k2, t1, t2) | hom_eq_tc , [k, t1, t2] <- args = Just $ print_equality (k, k, t1, t2) | otherwise = Nothing where homogeneous = case ifaceTyConSort $ ifaceTyConInfo tc of IfaceEqualityTyCon -> True _other -> False -- True <=> a heterogeneous equality whose arguments -- are (in this case) of the same kind tc_name = ifaceTyConName tc pp = ppr_ty hom_eq_tc = tc_name `hasKey` eqTyConKey -- (~) hetero_eq_tc = tc_name `hasKey` eqPrimTyConKey -- (~#) || tc_name `hasKey` eqReprPrimTyConKey -- (~R#) || tc_name `hasKey` heqTyConKey -- (~~) print_equality args = sdocWithDynFlags $ \dflags -> getPprStyle $ \style -> print_equality' args style dflags print_equality' (ki1, ki2, ty1, ty2) style dflags | print_eqs -- No magic, just print the original TyCon = ppr_infix_eq (ppr tc) | hetero_eq_tc , print_kinds || not homogeneous = ppr_infix_eq (text "~~") | otherwise = if tc_name `hasKey` eqReprPrimTyConKey then pprIfacePrefixApp ctxt_prec (text "Coercible") [pp TyConPrec ty1, pp TyConPrec ty2] else pprIfaceInfixApp ctxt_prec (char '~') (pp TyOpPrec ty1) (pp TyOpPrec ty2) where ppr_infix_eq eq_op = pprIfaceInfixApp ctxt_prec eq_op (parens (pp TopPrec ty1 <+> dcolon <+> pp TyOpPrec ki1)) (parens (pp TopPrec ty2 <+> dcolon <+> pp TyOpPrec ki2)) print_kinds = gopt Opt_PrintExplicitKinds dflags print_eqs = gopt Opt_PrintEqualityRelations dflags || dumpStyle style || debugStyle style }}} What to do? I'm not sure. But that's what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:11:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:11:53 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.40a003e8f54d72c46c12d11b2b15fa87@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: PartialTypeSignatures => PartialTypeSignatures, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:23:55 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down In-Reply-To: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> References: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> Message-ID: <059.458030ff074470ef171296359aeda8fa@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"803178a5383cdb5383e5b9fedd8feb3d65f9183b/ghc" 803178a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="803178a5383cdb5383e5b9fedd8feb3d65f9183b" users-guide: Override mathjax_path The Mathjax CDN no longer exists. Use CDNJS instead. See #15006. Test Plan: Build HTML users guide, see whether math is rendered. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: thomie, carter GHC Trac Issues: #15006 Differential Revision: https://phabricator.haskell.org/D4603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:24:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:24:04 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down In-Reply-To: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> References: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> Message-ID: <059.9b5962e5b1579d3a57484084e4361f02@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:24:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:24:24 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.81b76173965130fb1dd11d019dc61704@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 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: | Differential Rev(s): Phab:D4531 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f7f567d5003d15308bf5404301e29300b664e770/ghc" f7f567d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7f567d5003d15308bf5404301e29300b664e770" Add a test for #14815: Because the program doesn't have any binders that -XStrict can make strict, the desugarer output should be identical when it's compiled with and without -XStrict. This wasn't the case with GHC 8.2.2, but apparently it was fixed some time between 8.2.2 and 8.4.1. We now add a test case to make sure it stays fixed. Reviewers: bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14815 Differential Revision: https://phabricator.haskell.org/D4531 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:24:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:24:48 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.431718941afbc5494fff538c4f302427@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.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: | Differential Rev(s): Phab:D4531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: deSugar/T14815 (added) * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:54:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:54:54 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.ef5f8589c43d6b28e51a30b6e5515a56@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4611 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:55:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:55:17 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI Message-ID: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10037 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This should supposedly fail due to #10037. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:56:18 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.f914909f8a1eeac9df9c6722eda1929c@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: #10037 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Moreover, it unexpectedly fails in the `profasm` way: {{{ Actual prof output differs from expected: --- ./profiling/should_run/scc001.run/scc001.prof.sample.normalised 2018-04-19 14:18:58.342922502 +0000 +++ ./profiling/should_run/scc001.run/scc001.prof.normalised 2018-04-19 14:18:58.342922502 +0000 @@ -1,5 +1,5 @@ MAIN MAIN 0 (...) Main scc001.hs:16:1-16 1 -h Main scc001.hs:16:1-16 1 f Main scc001.hs:10:1-7 1 g Main scc001.hs:13:1-7 1 +h Main scc001.hs:16:1-16 1 *** unexpected failure for scc001(profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:56:57 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.b412daa4c23d36de625ee2e267063d9e@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: #10037 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See, for instance, https://circleci.com/gh/ghc/ghc/3654. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 16:58:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 16:58:44 -0000 Subject: [GHC] #15059: ghcpkg05 fails Message-ID: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> #15059: ghcpkg05 fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- Several people have noted that `ghcpkg05` seems to fail in some environments with (taken from CircleCI, https://circleci.com/gh/ghc/ghc/3654), {{{ --- ./cabal/ghcpkg05.run/ghcpkg05.stderr.normalised 2018-04-19 14:14:29.043902308 +0000 +++ ./cabal/ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-04-19 14:14:29.043902308 +0000 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX- ghc.so","libtestpkg-2.0-XXX-ghc.dylib","testpkg-2.0-XXX- ghc.dll"] on library path +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/haskeline/dist- install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/text/dist- install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/containers/dist- install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/bytestring/dist- install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 17:00:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 17:00:05 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.0d0a3f5d717a8636f3ee71fc39e72004@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: #10037 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This also fails on i386; see https://circleci.com/gh/ghc/ghc/3655. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 17:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 17:01:48 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.fd21b6e17732c4c445643eea11685141@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: #10037, #4012, | Differential Rev(s): #12935 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #10037 => #10037, #4012, #12935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 17:02:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 17:02:06 -0000 Subject: [GHC] #10037: Several profiling tests give different results optimised vs. unoptimised In-Reply-To: <047.efcb9e013309246f2cfca887b5137899@haskell.org> References: <047.efcb9e013309246f2cfca887b5137899@haskell.org> Message-ID: <062.e2bbdc85bd348d293701ef248902a90a@haskell.org> #10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15058, #4012, | Differential Rev(s): Phab:D4498 #12935 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #15058, #4012, #12935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 17:03:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 17:03:58 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 Message-ID: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Specifically in the `normal` way with, {{{ Actual stderr output differs from expected: --- ./rts/outofmem.run/outofmem.stderr-ws-32.normalised 2018-04-19 13:57:35.386373403 +0000 +++ ./rts/outofmem.run/outofmem.run.stderr.normalised 2018-04-19 13:57:35.386373403 +0000 @@ -1 +1,4 @@ -outofmem: out of memory (requested 1074790400 bytes) +outofmem: internal getMBlock: mmap: Invalid argument + (GHC version 8.5.20180419 for i386_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +Aborted *** unexpected failure for outofmem(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 17:09:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 17:09:21 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 Message-ID: <046.070201c29a49dce5435517538bdcfad1@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- CircleCI's i386 way is showing this failure of `print002` in the `ghci` way, {{{ Actual stderr output differs from expected: --- /dev/null 2018-04-18 16:05:23.479353000 +0000 +++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised 2018-04-19 13:53:47.685662431 +0000 @@ -0,0 +1 @@ +*** Exception: Prelude.chr: bad argument: 1493110744 *** unexpected failure for print022(ghci) }}} This is a bit frightening as it suggests that there is memory unsafety here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 18:30:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 18:30:39 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive Message-ID: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes: * Fails on Darwin (#2370) * Fails on POWER8 (#13634) * Fails on Win32 when in the `ghci` way (no ticket) * Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666) Perhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:11:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:11:00 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.3867feeabfc7b22e29ca09d1e711a099@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The failure of `T13825-debugger` on i386 in the `ghci` way looks very similar to this, {{{ Actual stdout output differs from expected: --- ./ghci.debugger/scripts/T13825-debugger.run/T13825-debugger.stdout.normalised 2018-04-19 18:13:10.621276834 +0000 +++ ./ghci.debugger/scripts/T13825-debugger.run/T13825-debugger.run.stdout.normalised 2018-04-19 18:13:10.621276834 +0000 @@ -4,5 +4,6 @@ packed2 = Packed2 12.34 56.78 42 99.99 Packed3 1 2 3 4 5 6 7.8 9.0 packed3 = Packed3 - (GHC.Word.W8# 1) (GHC.Int.I8# 2) (GHC.Int.I64# 3) (GHC.Word.W16# 4) - (GHC.Word.W64# 5) (GHC.Word.W32# 6) 7.8 9.0 + (GHC.Word.W8# 1) (GHC.Int.I8# 2) (GHC.Int.I64# 12884901891) + (GHC.Word.W16# 4) (GHC.Word.W64# 21474836485) (GHC.Word.W32# 6) 7.8 + 9.0 *** unexpected failure for T13825-debugger(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:14:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:14:28 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux Message-ID: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.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: -------------------------------------+------------------------------------- The `T3001-2` testcase fails on i386/Linux: {{{ Wrong exit code for T3001-2(prof_hb)(expected 0 , actual 134 ) Stderr ( T3001-2 ): T3001-2: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.5.20180419 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted *** unexpected failure for T3001-2(prof_hb) }}} Closure type 7 is `CONSTR_NOCAF`, which is indeed invalid. Tracking this down will take some debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:23:46 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM Message-ID: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (LLVM) | 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: -------------------------------------+------------------------------------- CircleCI's LLVM build revealed that `T8089` fails. The test is quite simple, {{{#!hs main = threadDelay maxBound }}} and is expected to timeout. However, it somehow exits with code 0 in all ways when built with LLVM. This didn't reproduce when I tried `make test TEST=T8089 EXTRA_HC_OPTS=-fllvm` locally, so either it's a library issue or environment-sensitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:24:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:24:04 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.40dc804f59ebb8efdd2ee274fd84e177@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Setting priority to highest as this may be miscompilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:25:43 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.4da1c5f25747fa5b975624235c85367f@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b08a6d75e0440f33260bea5319b8c3f871b42f6e/ghc" b08a6d75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b08a6d75e0440f33260bea5319b8c3f871b42f6e" Fix #15012 with a well-placed use of Any Previously, derived `Generic1` instances could have associated `Rep1` type family instances with unbound variables, such as in the following example: ```lang=haskell data T a = MkT (FakeOut a) deriving Generic1 type FakeOut a = Int ==> instance Generic1 T where type Rep1 T = ... (Rec0 (FakeOut a)) ``` Yikes! To avoid this, we simply map the last type variable in a derived `Generic1` instance to `Any`. Test Plan: make test TEST=T15012 Reviewers: bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, carter GHC Trac Issues: #15012 Differential Revision: https://phabricator.haskell.org/D4602 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:25:43 -0000 Subject: [GHC] #13450: Better parse error for empy character literal In-Reply-To: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> References: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> Message-ID: <065.80043df9cabdac2b2f413062ce6103f7@haskell.org> #13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T13450 | parser/should_fail/T13450TH Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4594 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cac8be611e7e80ed80e24b15faac9e1ac0a07247/ghc" cac8be6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cac8be611e7e80ed80e24b15faac9e1ac0a07247" Better error message for empty character literal, for Trac #13450. For empty character literal, the `''`, report error message properly rather than just throw a "parser error" with wrong error location. Test Plan: make test TEST="T13450 T13450TH" Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering, carter GHC Trac Issues: #13450 Differential Revision: https://phabricator.haskell.org/D4594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:25:43 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.912435230b771d6aa5b2127b48d3c5ad@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): D4546 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d9d801516dccab88b8083d34b465ee9ca8deb92f/ghc" d9d80151/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9d801516dccab88b8083d34b465ee9ca8deb92f" testsuite: Fix `./validate --slow` This fixes all unexpected passes and unexpected failures from a `./validate --slow` run I did last week. I commented on many tickets and created a few more as I was going through the failing tests. A summary of the entire process is available at: https://gist.github.com/alpmestan/c371840968f086c8dc5b56af8325f0a9 This is part of an attempt to have `./validate --slow` pass, tracked in #14890. Another patch will be necessary for the unexpected stats failures. Test Plan: ./validate --slow (not green yet) Reviewers: bgamari, simonmar Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:25:43 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.4ddd282d13f99e72cdbe1fcbca54635d@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4609 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f19ecc95fbaf2cc977531d721085d8441dc09b7/ghc" 8f19ecc9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f19ecc95fbaf2cc977531d721085d8441dc09b7" Bump base to version 4.12.0.0 Summary: Bumps several submodules. Test Plan: ./validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15018 Differential Revision: https://phabricator.haskell.org/D4609 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:38:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:38:52 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.67e2bbab5736a1492e13c41dac0981e0@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:39:48 -0000 Subject: [GHC] #13450: Better parse error for empy character literal In-Reply-To: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> References: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> Message-ID: <065.e7171913384554d66fbb89237f774053@haskell.org> #13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T13450 | parser/should_fail/T13450TH Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 19:44:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 19:44:35 -0000 Subject: [GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD In-Reply-To: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> References: <050.e61deb6ea526d2263cc0ea630972204d@haskell.org> Message-ID: <065.784b262f7c85a66f3b5ef4ddf58504c2@haskell.org> #15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15042 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4609 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 20:42:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 20:42:04 -0000 Subject: [GHC] #14997: mut_list_size calculation is off In-Reply-To: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> References: <043.7e40b5a5a3b89a9355ff8f8fca5917a0@haskell.org> Message-ID: <058.7b9a97faf681523db5d3acc959cec5cd@haskell.org> #14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: 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): Huh, I could have sworn that you were Jaffacake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:21:32 -0000 Subject: [GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples Message-ID: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> #15065: T12903(profasm) produces a heap profile with out of sequence samples -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: T12903(profasm) | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cd testsuite && make TEST="T12903" WAY="profasm" CLEANUP=0 ; cd .. [...] =====> T12903(profasm) 1 of 1 [0, 0, 0] cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" -o T12903 T12903.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 -O -prof -static -fprof-auto cd "./rts/T12903.run" && ./T12903 +RTS -hc -p -RTS cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/hp2ps" T12903 hp2ps error when processing heap profile for T12903 *** unexpected failure for T12903(profasm) [...] $ inplace/test\ \ \ spaces/hp2ps testsuite/tests/rts/T12903.run/T12903 hp2ps: testsuite/tests/rts/T12903.run/T12903.hp, line 9, samples out of sequence $ cat testsuite/tests/rts/T12903.run/T12903.hp JOB "T12903 +RTS -hc -p" DATE "Wed Apr 18 11:59 2018" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.004175 END_SAMPLE 0.004175 BEGIN_SAMPLE 0.000462 END_SAMPLE 0.000462 }}} This seems like an actual problem, completely unrelated to #12903, so I'm opening this ticket to track/fix this issue. I'll also mark T12903 as expected broken for the `profasm` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:22:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:22:53 -0000 Subject: [GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples In-Reply-To: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> References: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> Message-ID: <063.f12524af788e0ffbe26dfef9d1368704@haskell.org> #15065: T12903(profasm) produces a heap profile with out of sequence samples ---------------------------------+--------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T12903(profasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Changes (by alpmestan): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:24:17 -0000 Subject: [GHC] #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled In-Reply-To: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> References: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> Message-ID: <061.b19e55fbc5451e146381f7f5c34eb39d@haskell.org> #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled -------------------------------------+------------------------------------- Reporter: rotaerk | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | 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): * milestone: 8.4.2 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:33:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:33:23 -0000 Subject: [GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples In-Reply-To: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> References: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> Message-ID: <063.ee5ba414be087aaebb8679e835a77207@haskell.org> #15065: T12903(profasm) produces a heap profile with out of sequence samples ---------------------------------+--------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T12903(profasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Description changed by alpmestan: Old description: > {{{ > $ cd testsuite && make TEST="T12903" WAY="profasm" CLEANUP=0 ; cd .. > [...] > =====> T12903(profasm) 1 of 1 [0, 0, 0] > cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test > spaces/ghc-stage2" -o T12903 T12903.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 -O -prof -static -fprof-auto > cd "./rts/T12903.run" && ./T12903 +RTS -hc -p -RTS > cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test > spaces/hp2ps" T12903 > hp2ps error when processing heap profile for T12903 > *** unexpected failure for T12903(profasm) > [...] > $ inplace/test\ \ \ spaces/hp2ps testsuite/tests/rts/T12903.run/T12903 > hp2ps: testsuite/tests/rts/T12903.run/T12903.hp, line 9, samples out of > sequence > $ cat testsuite/tests/rts/T12903.run/T12903.hp > JOB "T12903 +RTS -hc -p" > DATE "Wed Apr 18 11:59 2018" > SAMPLE_UNIT "seconds" > VALUE_UNIT "bytes" > BEGIN_SAMPLE 0.000000 > END_SAMPLE 0.000000 > BEGIN_SAMPLE 0.004175 > END_SAMPLE 0.004175 > BEGIN_SAMPLE 0.000462 > END_SAMPLE 0.000462 > }}} > > This seems like an actual problem, completely unrelated to #12903, so I'm > opening this ticket to track/fix this issue. I'll also mark T12903 as > expected broken for the `profasm` way. New description: {{{ $ cd testsuite && make TEST="T12903" WAY="profasm" CLEANUP=0 ; cd .. [...] =====> T12903(profasm) 1 of 1 [0, 0, 0] cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" -o T12903 T12903.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 -O -prof -static -fprof-auto cd "./rts/T12903.run" && ./T12903 +RTS -hc -p -RTS cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/hp2ps" T12903 hp2ps error when processing heap profile for T12903 *** unexpected failure for T12903(profasm) [...] $ inplace/test\ \ \ spaces/hp2ps testsuite/tests/rts/T12903.run/T12903 hp2ps: testsuite/tests/rts/T12903.run/T12903.hp, line 9, samples out of sequence $ cat testsuite/tests/rts/T12903.run/T12903.hp JOB "T12903 +RTS -hc -p" DATE "Wed Apr 18 11:59 2018" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.004175 END_SAMPLE 0.004175 BEGIN_SAMPLE 0.000462 END_SAMPLE 0.000462 }}} This seems like an actual problem, completely unrelated to #12903, so I'm opening this ticket to track/fix this issue. I'll also mark T12903 as expected broken for the `profasm` way. EDIT: This was against 8b823f270e53627ddca1a993c05f1ab556742d96. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:34:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:34:20 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.83145fb6800987f0c2a241d0efb03a3d@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Very interesting; do you have any resource limits set in your system configuration? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:38:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:38:09 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.6f326bac2f23e30ad0a3f2b00d1cb8f5@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer 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): Great, looking forward to seeing it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 22:40:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 22:40:57 -0000 Subject: [GHC] #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways Message-ID: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways ----------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: EtaExpandLevPoly | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Against 8b823f270e53627ddca1a993c05f1ab556742d96: {{{#!hs $ make fulltest TEST=EtaExpandLevPoly [...] =====> EtaExpandLevPoly(normal) 1 of 1 [0, 0, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(hpc) 1 of 1 [0, 0, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -fhpc cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(optasm) 1 of 1 [0, 0, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -fasm cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(profasm) 1 of 1 [0, 0, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( EtaExpandLevPoly.hs, EtaExpandLevPoly.o ) *** Core Lint errors : in result of Simplifier *** : warning: In the type ‘((# Bool, Int# #) |> Sym (TYPE (Sym co_a1ww))_N)’ co_a1ww :: (a_a1wt :: RuntimeRep) ~# ('TupleRep '['LiftedRep, 'IntRep] :: RuntimeRep) [LclId[CoVarId]] is out of scope *** Offending Program *** foo :: forall b. G 'LiftedRep -> b -> b [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] foo = \ (@ (a_a1wt :: RuntimeRep)) (@ (b_a1wu :: TYPE a_a1wt)) (ds_d1Pr :: G a_a1wt) -> scctick case ds_d1Pr of { MkG co_a1ww -> \ (x_a10m :: (b_a1wu |> Sym (TYPE (Sym co_a1ww))_N)) -> tick x_a10m } bar :: forall a. H 'LiftedRep -> (a -> a -> (# a, a #)) -> a -> (# a, a #) [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 60 60}] bar = \ (@ (r_a1vB :: RuntimeRep)) (@ (a_a1vC :: TYPE r_a1vB)) (ds_d1Pk :: H r_a1vB) -> scctick case ds_d1Pk of { MkH co_a1vE -> (\ (f_a10o :: (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) -> (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) -> (# (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N), (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) #)) (x_a10p :: (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N)) -> scctick f_a10o x_a10p x_a10p) `cast` ((Coh _R (TYPE co_a1vE)_N ->_R Coh _R (TYPE co_a1vE)_N ->_R ((#,#) (Sub (Sym co_a1vE)) (Sub (Sym co_a1vE)) (Coh _R (TYPE co_a1vE)_N) (Coh _R (TYPE co_a1vE)_N))_R) ->_R Coh _R (TYPE co_a1vE)_N ->_R ((#,#) (Sub (Sym co_a1vE)) (Sub (Sym co_a1vE)) (Coh _R (TYPE co_a1vE)_N) (Coh _R (TYPE co_a1vE)_N))_R :: (((a_a1vC |> (TYPE co_a1vE)_N) -> (a_a1vC |> (TYPE co_a1vE)_N) -> (# (a_a1vC |> (TYPE co_a1vE)_N), (a_a1vC |> (TYPE co_a1vE)_N) #)) -> (a_a1vC |> (TYPE co_a1vE)_N) -> (# (a_a1vC |> (TYPE co_a1vE)_N), (a_a1vC |> (TYPE co_a1vE)_N) #) :: *) ~R# ((a_a1vC -> a_a1vC -> (# a_a1vC, a_a1vC #)) -> a_a1vC -> (# a_a1vC, a_a1vC #) :: *)) } $trModule_s245 :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s245 = "main"# $trModule_s246 :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s246 = TrNameS $trModule_s245 $trModule_s247 :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s247 = "Main"# $trModule_s248 :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s248 = TrNameS $trModule_s247 $trModule :: Module [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_s246 $trModule_s248 $krep_a1P3 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P3 = KindRepTyConApp $tc'LiftedRep ([] @ KindRep) $krep_a1OZ [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OZ = KindRepTyConApp $tc'IntRep ([] @ KindRep) $krep_a1OX [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OX = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) $krep_a1OW [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OW = KindRepFun $krep_a1OX krep$* $krep_s249 :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s249 = : @ KindRep $krep_a1OX ([] @ KindRep) $krep_a1P5 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P5 = KindRepTyConApp $tc'[] $krep_s249 $krep_s24a :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24a = : @ KindRep $krep_a1P5 ([] @ KindRep) $krep_s24b :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24b = : @ KindRep $krep_a1OZ $krep_s24a $krep_s24c :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24c = : @ KindRep $krep_a1OX $krep_s24b $krep_a1P4 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P4 = KindRepTyConApp $tc': $krep_s24c $krep_s24d :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24d = : @ KindRep $krep_a1P4 ([] @ KindRep) $krep_s24e :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24e = : @ KindRep $krep_a1P3 $krep_s24d $krep_s24f :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24f = : @ KindRep $krep_a1OX $krep_s24e $krep_a1P2 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P2 = KindRepTyConApp $tc': $krep_s24f $krep_s24g :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24g = : @ KindRep $krep_a1P2 ([] @ KindRep) $krep_a1P1 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P1 = KindRepTyConApp $tc'TupleRep $krep_s24g $tcG_s24h :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tcG_s24h = "G"# $tcG_s24i :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tcG_s24i = TrNameS $tcG_s24h $tcG :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tcG = TyCon 14221008574166376522## 17210926818700297107## $trModule $tcG_s24i 0# $krep_a1OW $krep_s24j :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24j = : @ KindRep $krep_a1P1 ([] @ KindRep) $krep_a1P0 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P0 = KindRepTyConApp $tcG $krep_s24j $tc'MkG_s24k :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tc'MkG_s24k = "'MkG"# $tc'MkG_s24l :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tc'MkG_s24l = TrNameS $tc'MkG_s24k $tc'MkG :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tc'MkG = TyCon 11219666876303220503## 4566534404187760096## $trModule $tc'MkG_s24l 0# $krep_a1P0 $tcH_s24m :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tcH_s24m = "H"# $tcH_s24n :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tcH_s24n = TrNameS $tcH_s24m $tcH :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tcH = TyCon 5827673930009354874## 4277163490596771739## $trModule $tcH_s24n 0# $krep_a1OW $krep_s24o :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24o = : @ KindRep $krep_a1OZ ([] @ KindRep) $krep_a1OY [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OY = KindRepTyConApp $tcH $krep_s24o $tc'MkH_s24p :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tc'MkH_s24p = "'MkH"# $tc'MkH_s24q :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tc'MkH_s24q = TrNameS $tc'MkH_s24p $tc'MkH :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tc'MkH = TyCon 273175143458456096## 17487285292499736820## $trModule $tc'MkH_s24q 0# $krep_a1OY main :: IO () [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 510 0}] main = scctick
case (tick \ (x_a10m :: ((# Bool, Int# #) |> Sym (TYPE (Sym co_a1ww))_N)) -> scc tick x_a10m) (# True, 3# #) of ds_d23V { (# ipv_s24s, ipv_s24t #) -> (\ (s_a24P :: State# RealWorld) -> case ((hPutStr' stdout ($fShowBool_$cshow ipv_s24s) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) s_a24P of { (# ipv_a24S, ipv1_a24T #) -> case ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s24t) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_a24S of { (# ipv_X265, ipv1_X267 #) -> ((case (scctick case $WMkH of { MkH co_a1vE -> \ (f_a10o :: Int# -> Int# -> (# Int#, Int# #)) (x_a10p :: Int#) -> scctick f_a10o x_a10p x_a10p }) ((#,#) @ 'IntRep @ 'IntRep @ Int# @ Int#) 8# of ds_d23T { (# ipv_s25y, ipv_s25z #) -> (\ (s_X26d :: State# RealWorld) -> case ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s25y) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) s_X26d of { (# ipv_X26j, ipv1_X26l #) -> ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s25z) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_X26j }) `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) }) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_X265 } }) `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) } main_s3to :: State# RealWorld -> (# State# RealWorld, () #) [LclId, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s3to = runMainIO1 @ () main main :: IO () [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] main = main_s3to `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) *** End of Offense *** : error: Compilation had errors *** unexpected failure for EtaExpandLevPoly(profasm) =====> EtaExpandLevPoly(threaded1) 1 of 1 [0, 1, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -threaded -debug cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(threaded2) 1 of 1 [0, 1, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -threaded -eventlog cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly +RTS -N2 -ls -RTS =====> EtaExpandLevPoly(dyn) 1 of 1 [0, 1, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -dynamic cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(profthreaded) 1 of 1 [0, 1, 0] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/home/alp/ghc-slow- validate/inplace/test spaces/ghc-stage2" -o EtaExpandLevPoly EtaExpandLevPoly.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 -O -prof -static -fprof-auto -threaded Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( EtaExpandLevPoly.hs, EtaExpandLevPoly.o ) *** Core Lint errors : in result of Simplifier *** : warning: In the type ‘((# Bool, Int# #) |> Sym (TYPE (Sym co_a1ww))_N)’ co_a1ww :: (a_a1wt :: RuntimeRep) ~# ('TupleRep '['LiftedRep, 'IntRep] :: RuntimeRep) [LclId[CoVarId]] is out of scope *** Offending Program *** foo :: forall b. G 'LiftedRep -> b -> b [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] foo = \ (@ (a_a1wt :: RuntimeRep)) (@ (b_a1wu :: TYPE a_a1wt)) (ds_d1Pr :: G a_a1wt) -> scctick case ds_d1Pr of { MkG co_a1ww -> \ (x_a10m :: (b_a1wu |> Sym (TYPE (Sym co_a1ww))_N)) -> tick x_a10m } bar :: forall a. H 'LiftedRep -> (a -> a -> (# a, a #)) -> a -> (# a, a #) [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 60 60}] bar = \ (@ (r_a1vB :: RuntimeRep)) (@ (a_a1vC :: TYPE r_a1vB)) (ds_d1Pk :: H r_a1vB) -> scctick case ds_d1Pk of { MkH co_a1vE -> (\ (f_a10o :: (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) -> (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) -> (# (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N), (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N) #)) (x_a10p :: (a_a1vC |> Sym (TYPE (Sym co_a1vE))_N)) -> scctick f_a10o x_a10p x_a10p) `cast` ((Coh _R (TYPE co_a1vE)_N ->_R Coh _R (TYPE co_a1vE)_N ->_R ((#,#) (Sub (Sym co_a1vE)) (Sub (Sym co_a1vE)) (Coh _R (TYPE co_a1vE)_N) (Coh _R (TYPE co_a1vE)_N))_R) ->_R Coh _R (TYPE co_a1vE)_N ->_R ((#,#) (Sub (Sym co_a1vE)) (Sub (Sym co_a1vE)) (Coh _R (TYPE co_a1vE)_N) (Coh _R (TYPE co_a1vE)_N))_R :: (((a_a1vC |> (TYPE co_a1vE)_N) -> (a_a1vC |> (TYPE co_a1vE)_N) -> (# (a_a1vC |> (TYPE co_a1vE)_N), (a_a1vC |> (TYPE co_a1vE)_N) #)) -> (a_a1vC |> (TYPE co_a1vE)_N) -> (# (a_a1vC |> (TYPE co_a1vE)_N), (a_a1vC |> (TYPE co_a1vE)_N) #) :: *) ~R# ((a_a1vC -> a_a1vC -> (# a_a1vC, a_a1vC #)) -> a_a1vC -> (# a_a1vC, a_a1vC #) :: *)) } $trModule_s245 :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s245 = "main"# $trModule_s246 :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s246 = TrNameS $trModule_s245 $trModule_s247 :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s247 = "Main"# $trModule_s248 :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s248 = TrNameS $trModule_s247 $trModule :: Module [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_s246 $trModule_s248 $krep_a1P3 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P3 = KindRepTyConApp $tc'LiftedRep ([] @ KindRep) $krep_a1OZ [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OZ = KindRepTyConApp $tc'IntRep ([] @ KindRep) $krep_a1OX [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OX = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) $krep_a1OW [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OW = KindRepFun $krep_a1OX krep$* $krep_s249 :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s249 = : @ KindRep $krep_a1OX ([] @ KindRep) $krep_a1P5 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P5 = KindRepTyConApp $tc'[] $krep_s249 $krep_s24a :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24a = : @ KindRep $krep_a1P5 ([] @ KindRep) $krep_s24b :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24b = : @ KindRep $krep_a1OZ $krep_s24a $krep_s24c :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24c = : @ KindRep $krep_a1OX $krep_s24b $krep_a1P4 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P4 = KindRepTyConApp $tc': $krep_s24c $krep_s24d :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24d = : @ KindRep $krep_a1P4 ([] @ KindRep) $krep_s24e :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24e = : @ KindRep $krep_a1P3 $krep_s24d $krep_s24f :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24f = : @ KindRep $krep_a1OX $krep_s24e $krep_a1P2 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P2 = KindRepTyConApp $tc': $krep_s24f $krep_s24g :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24g = : @ KindRep $krep_a1P2 ([] @ KindRep) $krep_a1P1 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P1 = KindRepTyConApp $tc'TupleRep $krep_s24g $tcG_s24h :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tcG_s24h = "G"# $tcG_s24i :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tcG_s24i = TrNameS $tcG_s24h $tcG :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tcG = TyCon 14221008574166376522## 17210926818700297107## $trModule $tcG_s24i 0# $krep_a1OW $krep_s24j :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24j = : @ KindRep $krep_a1P1 ([] @ KindRep) $krep_a1P0 [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1P0 = KindRepTyConApp $tcG $krep_s24j $tc'MkG_s24k :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tc'MkG_s24k = "'MkG"# $tc'MkG_s24l :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tc'MkG_s24l = TrNameS $tc'MkG_s24k $tc'MkG :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tc'MkG = TyCon 11219666876303220503## 4566534404187760096## $trModule $tc'MkG_s24l 0# $krep_a1P0 $tcH_s24m :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tcH_s24m = "H"# $tcH_s24n :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tcH_s24n = TrNameS $tcH_s24m $tcH :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tcH = TyCon 5827673930009354874## 4277163490596771739## $trModule $tcH_s24n 0# $krep_a1OW $krep_s24o :: [KindRep] [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_s24o = : @ KindRep $krep_a1OZ ([] @ KindRep) $krep_a1OY [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $krep_a1OY = KindRepTyConApp $tcH $krep_s24o $tc'MkH_s24p :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $tc'MkH_s24p = "'MkH"# $tc'MkH_s24q :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $tc'MkH_s24q = TrNameS $tc'MkH_s24p $tc'MkH :: TyCon [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] $tc'MkH = TyCon 273175143458456096## 17487285292499736820## $trModule $tc'MkH_s24q 0# $krep_a1OY main :: IO () [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 510 0}] main = scctick
case (tick \ (x_a10m :: ((# Bool, Int# #) |> Sym (TYPE (Sym co_a1ww))_N)) -> scc tick x_a10m) (# True, 3# #) of ds_d23V { (# ipv_s24s, ipv_s24t #) -> (\ (s_a24P :: State# RealWorld) -> case ((hPutStr' stdout ($fShowBool_$cshow ipv_s24s) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) s_a24P of { (# ipv_a24S, ipv1_a24T #) -> case ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s24t) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_a24S of { (# ipv_X265, ipv1_X267 #) -> ((case (scctick case $WMkH of { MkH co_a1vE -> \ (f_a10o :: Int# -> Int# -> (# Int#, Int# #)) (x_a10p :: Int#) -> scctick f_a10o x_a10p x_a10p }) ((#,#) @ 'IntRep @ 'IntRep @ Int# @ Int#) 8# of ds_d23T { (# ipv_s25y, ipv_s25z #) -> (\ (s_X26d :: State# RealWorld) -> case ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s25y) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) s_X26d of { (# ipv_X26j, ipv1_X26l #) -> ((hPutStr' stdout (showSignedInt $fShow(,)1 (I# ipv_s25z) ([] @ Char)) True) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_X26j }) `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) }) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# (State# RealWorld -> (# State# RealWorld, () #) :: *))) ipv_X265 } }) `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) } main_s3to :: State# RealWorld -> (# State# RealWorld, () #) [LclId, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s3to = runMainIO1 @ () main main :: IO () [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] main = main_s3to `cast` (Sym (N:IO[0] <()>_R) :: (State# RealWorld -> (# State# RealWorld, () #) :: *) ~R# (IO () :: *)) *** End of Offense *** : error: Compilation had errors *** unexpected failure for EtaExpandLevPoly(profthreaded) Unexpected results from: TEST="EtaExpandLevPoly" SUMMARY for test run started at Fri Apr 20 00:34:52 2018 CEST 0:00:05 spent to go through 1 total tests, which gave rise to 9 test cases, of which 1 were skipped 0 had missing libraries 6 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 2 unexpected failures 0 unexpected stat failures Unexpected failures: typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profasm) typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profthreaded) }}} I'll mark the test as expected broken in those ways for now, linking to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 23:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 23:20:16 -0000 Subject: [GHC] #15048: Fix mirroring of terminfo and haskeline In-Reply-To: <046.c3a7e83293fc0e262628d22ca9c5dd3f@haskell.org> References: <046.c3a7e83293fc0e262628d22ca9c5dd3f@haskell.org> Message-ID: <061.59cfff0d567fdef99ec4504d8e572b85@haskell.org> #15048: Fix mirroring of terminfo and haskeline -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Trac & Git | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `transformers` is another one of these packages whose mirroring situation seems odd to me. http://git.haskell.org/ has //two// repos for `transformers`. One, http://git.haskell.org/darcs- mirrors/transformers.git, is a direct mirror of the darcs repo at https://hub.darcs.net/ross/transformers (which updates automatically), while the other, http://git.haskell.org/packages/transformers.git, is an upstream repo //à la// `terminfo` and `haskeline`. However, GHC uses the latter, which requires manual updates! Since we're planning to fix this for `terminfo` and `haskeline`, can we also do the same for `transformers`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 23:35:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 23:35:37 -0000 Subject: [GHC] #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways In-Reply-To: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> References: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> Message-ID: <063.e9c756ef71b4b37c6052d97b0512b90b@haskell.org> #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways ---------------------------------+---------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: EtaExpandLevPoly Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): I can also reproduce this with GHC 8.4.1 when compiling with `-prof -fprof-auto -O1` (or `-O2`). Here is a slightly more minimal reproduction: {{{#!hs {-# LANGUAGE UnboxedTuples, GADTs, TypeInType, ExplicitForAll #-} module Bug where import GHC.Exts data G a where MkG :: G (TupleRep '[LiftedRep]) foo :: forall a (b :: TYPE a). G a -> b -> b foo MkG = (\x -> x) :: forall (c :: TYPE (TupleRep '[LiftedRep])). c -> c main :: IO () main = let (# b #) = foo MkG (# True #) in print b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 19 23:49:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Apr 2018 23:49:31 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.ae665c9d06d45403f0193911b76d90d7@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, that's one half of the mystery (2). Do you know why (1) is happening? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:02:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:02:39 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.b46599fcb307aa3e6abcd8591f545fc4@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: kanetw Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by kanetw): * owner: (none) => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:03:03 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.28b9738637a2386e4b0cd9c10dac8ee8@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: kanetw Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4607 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by kanetw): * status: new => patch * differential: => D4607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:04:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:04:01 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.b2708042e7a067a3349891e033e0f6c3@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: kanetw Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4607 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by kanetw): * differential: D4607 => Phab:D4607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:15:27 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics Message-ID: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: Typeable, | Operating System: Unknown/Multiple UnboxedSums | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program is enough to send GHC into a tizzy: {{{#!hs {-# LANGUAGE UnboxedSums #-} module Bug1 where import Type.Reflection floopadoop :: TypeRep (# Bool | Int #) floopadoop = typeRep }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug1 ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): tyConRep (#|#) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsBinds.hs:1314:5 in ghc:DsBinds }}} If you use an unboxed sum data constructor, you can get a different panic: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} module Bug2 where import Language.Haskell.TH import Type.Reflection type Fweemp = $(conT (unboxedSumDataName 1 2)) doopafloop :: _ => TypeRep Fweemp doopafloop = typeRep }}} {{{ $ ghc Bug2.hs [1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o ) GHC error in desugarer lookup in Bug2: Can't find interface-file declaration for variable $tc'(#_|#) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): initDs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:16:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:16:02 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.1a4b4a72d42018721078a3b441faaf39@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: | UnboxedSums 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): * failure: None/Unknown => Compile-time crash or panic * version: 8.2.2 => 8.4.1 * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 00:20:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 00:20:44 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.d84e9ff36f92ec7b6af559702e761117@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => Phab:D4612 Comment: Submitted a patch for (1). (The OSX appears to be stuck. It's running for "5 h, 57 m". I might restart it if it doesn't finish in the next couple hours. ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 01:50:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 01:50:28 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.7ebdcb1dbfb61699e3fd2e7589452c09@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by goldfire): The idea is that, with `-fprint-explicit-kinds`, `(a ~~ b)` should be printed as `((a :: *) ~~ (b :: *))`, with the explicit kinds. But `(a ~# b)` should ''also'' be printed as `((a :: *) ~~ (b :: *))`, so as not to expose the user to `~#`. Note that `(a ~ b)` is just printed as `(a ~ b)`, even with `-fprint-explicit-kinds`, which seems wrong. And, of course, `~R#` should never be printed with `~~`. What to do? Here are the cases. Assume `a :: *`, `b :: *`, and `c :: k`. 1. Homogeneous equality `a ~ b`. 2. Homogeneous use of heterogeneous equality `a ~~ b`. 3. Heterogeneous use of heterogeneous equality `a ~~ c`. 4. Homogeneous use of unlifted equality `a ~# b`. 5. Heterogeneous use of unlifted equality `a ~# c`. 6. Homegeneous representational equality `Coercible a b`. 7. Homogeneous use of representational unlifted equality `a ~#R b`. 8. Heterogeneous use of representational unlifted equality `a ~R# c`. Note that there is no heterogeneous representational lifted equality (the counterpert to `~~`). There could be, but there seems to be no use for it. For each case, we must decide how to print a. By default b. With `-fprint-explicit-kinds` c. With `-fprint-equality-relations` d. With `-fprint-explicit-kinds -fprint-equality-relations`. I propose: 1. a. `a ~ b` b. `(a :: *) ~ (b :: *)` c. `a ~ b` d. `(a :: *) ~ (b :: *)` 2. a. `a ~ b` b. `(a :: *) ~ (b :: *)` c. `a ~~ b` d. `(a :: *) ~~ (b :: *)` 3. a. `a ~~ c` b. `(a :: *) ~~ (c :: k)` c. `a ~~ c` d. `(a :: *) ~~ (c :: k)` 4. a. `a ~ b` b. `(a :: *) ~ (b :: *)` c. `a ~# b` d. `(a :: *) ~# (b :: *)` 5. a. `a ~~ c` b. `(a :: *) ~~ (c :: k)` c. `a ~# c` d. `(a :: *) ~# (c :: k)` 6. a. `Coercible a b` b. `Coercible * a b` c. `Coercible a b` d. `Coercible * a b` 7. a. `Coercible a b` b. `Coercible * a b` c. `a ~R# b` d. `(a :: *) ~R# (b :: *)` 8. a. `a ~R# c` b. `(a :: *) ~R# (c :: k)` c. `a ~R# c` d. `(a :: *) ~R# (c :: k)` Here are the rules: A. With `-fprint-equality-relations`, print the true equality relation. B. Without `-fprint-equality-relations`: i. If the equality is representational and homogeneous, use `Coercible`. ii. Otherwise, if the equality is representational, use `~R#`. iii. If the equality is nominal and homogeneous, use `~`. iv. Otherwise, if the equality is nominal, use `~~`. C. With `-fprint-explicit-kinds`, print kinds on both sides of an infix operator, as above; or print the kind with `Coercible`. D. Without `-fprint-explicit-kinds`, don't print kinds. I believe that my examples above conform to these rules. Do we agree with this approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 03:00:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 03:00:32 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.c494c348152cdc88563aaf7e3174c5db@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"257c13d86db0a9ed540287127fd1c79abacf857e/ghc" 257c13d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="257c13d86db0a9ed540287127fd1c79abacf857e" Lint types in newFamInst We weren't linting the types used in `newFamInst`, which might have been why #15012 went undiscovered for so long. Let's fix that. One has to be surprisingly careful with expanding type synonyms in `lintType`, since in the offending program (simplified): ```lang=haskell type FakeOut a = Int type family TF a type instance TF Int = FakeOut a ``` If one expands type synonyms, then `FakeOut a` will expand to `Int`, which masks the issue (that `a` is unbound). I added an extra Lint flag to configure whether type synonyms should be expanded or not in Lint, and disabled this when calling `lintTypes` from `newFamInst`. As evidence that this works, I ran it on the offending program from #15012, and voilà: ``` $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180417 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘... (Rec0 (FakeOut b_a1Qt))))’ @ b_a1Qt is out of scope ``` Test Plan: make test TEST=T15057 Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15057 Differential Revision: https://phabricator.haskell.org/D4611 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 03:00:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 03:00:32 -0000 Subject: [GHC] #15012: "Iface type variable out of scope" when compiling with -c In-Reply-To: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> References: <050.84b485db2c9f862ab8a431cfb617a344@haskell.org> Message-ID: <065.db5ec5854279cfed68f95974464c476e@haskell.org> #15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"257c13d86db0a9ed540287127fd1c79abacf857e/ghc" 257c13d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="257c13d86db0a9ed540287127fd1c79abacf857e" Lint types in newFamInst We weren't linting the types used in `newFamInst`, which might have been why #15012 went undiscovered for so long. Let's fix that. One has to be surprisingly careful with expanding type synonyms in `lintType`, since in the offending program (simplified): ```lang=haskell type FakeOut a = Int type family TF a type instance TF Int = FakeOut a ``` If one expands type synonyms, then `FakeOut a` will expand to `Int`, which masks the issue (that `a` is unbound). I added an extra Lint flag to configure whether type synonyms should be expanded or not in Lint, and disabled this when calling `lintTypes` from `newFamInst`. As evidence that this works, I ran it on the offending program from #15012, and voilà: ``` $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180417 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘... (Rec0 (FakeOut b_a1Qt))))’ @ b_a1Qt is out of scope ``` Test Plan: make test TEST=T15057 Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15057 Differential Revision: https://phabricator.haskell.org/D4611 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 03:00:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 03:00:47 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.8fc9ab30d903eb8463142d3f195c0093@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Azel Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4593 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a26983a3aef25b3fa5f66b4d68ea7240a6dd1543/ghc" a26983a3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a26983a3aef25b3fa5f66b4d68ea7240a6dd1543" Fixes isAlphaNum re. isAlpha/isNumber and doc fix (trac issue #10412) Corrects the inconsistency between Data.Char.isAlphaNum, Data.Char.isAlpha and Data.Char.isNumber. Indeed, isAlphaNum was returning True not only when isAlpha or isNumber returned True but also when isMark did. The selectors for the Mn, Mc and Me general categories where removed from the macro generating u_iswalnum in ubconfc. Also, Data.Char.isAlphaNum's documentation was changed to state that isAlphaNum returns true not only for Unicode number digits but for Unicode numbers in general in Unicode.hs. Signed-off-by: ARJANEN Loïc Jean David Reviewers: hvr, ekmett, lelf, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #10412 Differential Revision: https://phabricator.haskell.org/D4593 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 03:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 03:34:59 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.413ae14139dacb34cc2b252e410308c3@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Azel Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: unicode, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4593 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 03:35:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 03:35:32 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.4792db0101a0868d48ac7af210629a56@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 07:54:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 07:54:31 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.3102d2da1f7ec46e6604ccc60d6cf64f@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for doing this, but I don't think it's quite right yet. As you have it, we * Expand type synonyms usually * But not when calling from `newFamInst` But that isn't what we want. Consider these definitions: {{{ type S1 x = Int type S2 x = x Int }}} In regular Core, if `a` is not in scope, it'd be bad to have a type `S1 a`. Likewise `S2 (Int Int)` would be bad (kind error). With your patch this will be missed. Moreover, in `newFamInst`, it's ok to have a RHS with a partially-applied type synonym like `S2 S1`. But I think your patch will reject it. What we want is something like this: * In a type-synonym application `S t1 .. tn`: 1. Expand the synonym and lint the result 2. But also lint `t1..tn` independently, to find any out-of-scope variables or kind errors The trouble is that in `t1..tn` we are allowed to have an un-saturated synonym application, ''but only at top level''. For example, suppose {{{ }}} Then `S2 S1` is fine, but `S2 (Maybe S1)` is not. Of course, the latter is detected in step (1). But it won't be detected in `S1 (Maybe S1)`. I think I don't care about that; un-saturated synonyms in a phantom argument. So that would make the rule be as follows: * Have a flag report-unsat-syns * In a type-synonym application `S t1 .. tn`: 1. If report-unsat-syns is on, and `S` has arity more than n, report an unsaturated synonym 2. If report-unsat-syns is on, expand the synonym and lint the result 3. Regardless of report-unsat-syns, lint `t1..tn` independently with report-unsat-syns off, to find any out-of-scope variables or kind errors * Switch on report-unsat-syns for the arguments of `AppTy` and `TyConApp` with non-synonym type constructor. There is some duplicated work here: for non-phantom arguments, if report- unsat-syns is on, all the work of (3) is done by (2). So you could do (3) only for phantom arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 08:33:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 08:33:27 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.a8fab7706ea95156beed409dd8c57ad1@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by simonpj): That looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 08:38:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 08:38:46 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.31b2c5068bcc665ee6e98d36706f90a7@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 08:44:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 08:44:40 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.d9d8cc8b3ad5d9425b3777110e331aac@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What you propose sounds fine. But I'm not going to be working on it, as I've already exceeded my time budget for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 08:49:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 08:49:40 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.4646cce904b934bd0974b4b2f38eaebf@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fair enough. But meanwhile perhaps we can revert the patch, since it adds complexity but does not achieve the goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 08:55:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 08:55:28 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.9aba298d29d11ec1987360fb1bcf6f45@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): comment:5 sounds fine, but it only addresses problem (2). What about problem (1)? We still have GHC reporting that the kind of `Coercible a b` is `TYPE (TupleRep '[])`, which is utterly bogus. It seems like if `-fprint-equality-relations` is disabled, then we'd want to print the kind `Constraint` instead, yes? Is that feasible with the way partial type signature reporting currently works? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 09:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 09:40:31 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.baa576eed2d51581222be03690205d55@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 09:49:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 09:49:57 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.f3f7bd0c339d5469225e796a4146c244@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: | UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13276 Comment: Ah, #13276 claims that unboxed sums shouldn't be `Typeable` at all. I'm fine with this, but it would be nice to have a proper error message in the event one tries to do this instead of panicking. (The commit which established this limitation, 42ff5d97b486d50b0d10e474f47e86822bb71ace, didn't add any regression tests, which might explain why these infelicities went unnoticed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 09:52:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 09:52:11 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.8ca9c25803f2d6f61ed044b30d725a88@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable, | UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261, #15067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13261 => #13261, #15067 Comment: Unfortunately, trying to combine unboxed sums with `Typeable` is still quite susceptible to GHC panics, as shown in #15067. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 10:32:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 10:32:40 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) Message-ID: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: T13658 | Blocked By: T14779a T14779b T14868 debug | parsing001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A few tests (T13658 T14779a T14779b T14868 debug parsing001) fail running validate using HEAD and 8.4.1. They produce output similar to that shown below. I am not quite sure how to test with clang. Just setting and exporting the environment variable CC to /usr/bin/clang (6) and running validate seemed to produce similar failures. I was unable to try with LLVM because that now seems to be on version 6, which doesn't build. {{{ =====> cgrun004(normal) 290 of 6344 [0, 0, 0] cd "/tmp/ghctest-lx7q03iz/test spaces/./codeGen/should_run/cgrun004.run" && "/home/jrp/Projects/ghc/bindisttest/install dir/bin /ghc" -o cgrun004 cgrun004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-gr oups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output Wrong exit code for debug()(expected 0 , actual 2 ) Stdout ( debug ): == Dbg == src src src src src src src src src src src Makefile:12: recipe for target 'debug' failed Stderr ( debug ): /tmp/ghc152350_0/ghc_2.s: Assembler messages: /tmp/ghc152350_0/ghc_2.s:1364:0: error: Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-' /tmp/ghc152350_0/ghc_2.s:1393:0: error: Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-' /tmp/ghc152350_0/ghc_2.s:1422:0: error: Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-' /tmp/ghc152350_0/ghc_2.s:1451:0: error: Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-' `gcc' failed in phase `Assembler'. (Exit code: 1) make[1]: ./debug: Command not found make[1]: *** [debug] Error 127 *** unexpected failure for debug(normal) }}} The tool versions are: {{{ GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30 }}} {{{ COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --program- prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default- libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib- list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload- targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:09:41 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.7238fd7484772d5e80b1cad1fc3d911b@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14998 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #14998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:12:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:12:22 -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.7d5027101e40db02ab6e679e8b596e9a@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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Just to sum up this thread so far: - Item 1 (make `catchRetry#` lazy) was merged and @dfeuer works on removing `ExnStr` from `Demand.hs` on `wip/no-exnstr`. - Item 2 was about finding out where things regress if we got rid of the strictness introduced in `catchException` and `catchAny`. I summarised my debugging sessions in [comment:16]. - Item 3 (make `catch#` strict and see if it improves things) was handled in [comment:2]. Contrary to prior measurements, I couldn't make out huge improvements, probably due to [comment:17]. I didn't bother to pinpoint where the -0.1% came from, though. - Item 4 (IO hack) isn't fully resolved yet, but I addressed it in [comment:21]. @dfeuer (probably?) wrote down his thoughts on this on [wiki:Exceptions/PreciseExceptions#Implementingpreciseexceptions]. - Item 5 (strictness of `raiseIO#`) is still open. I don't think I can address this at all, lacking too much background. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:13:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:13:50 -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.d14a401907824705367ee1860989b82b@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 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 sgraf): * related: => #11555 #13330 #10712 #11222 #13380 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:23:06 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.40f775e9d5b0e8a7d78ec8c9d2532e88@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #8763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:27:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:27:47 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.1815e803a36eb9ee123423acfdfb1247@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:61 simonpj]: > Looks plausible to me, but needs a careful Note to explain the issues. > > But before we go too far with this, I'd like to point to [wiki:LateLamLift late lambda lifting]. In the core reported in comment:44, all we need to do is lambda-lift `$wc` and `go_up` to top level, and all will be well, I claim. And that is precisely what late- lambda lifting does. And the result might be faster than the very careful code above, because of the extra argument passing and case-tesing it has to do. > > To me LLF is low-hanging fruit. There are promising results described on the wiki page, and the whole join-point business eliminates its principal shortcoming. > > I wonder if, before going ahead with this somewhat-delicate `efdtIntFB` business, it might be fun to re-awaken LLF? I'll give it a try. Without understanding all operational consequences of LLF, I'd still guess that making sure all `c`s inline would be more beneficial in this scenario. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 11:50:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 11:50:21 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.8886873652e33738e48505608375d56f@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'll give it a try. Without understanding all operational consequences of LLF, I'd still guess that making sure all cs inline would be more beneficial in this scenario. In general inlining is good. But in the case on this thread, I think it's the non-allocation of a function closure that saves all the work, rather than any optimisations that happen after inlining c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 12:14:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 12:14:19 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.17e07be5eb5b95f934d15c491171c962@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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 ckoparkar): * owner: (none) => ckoparkar Comment: I should have a patch ready shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 12:31:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 12:31:44 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.fa2d2ab8fe4a5a35a6d340d2ebe70132@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another example comes from `nofib/real/veritas`. In `Edlib.hs` we have {{{ (...) :: Xio_fn -> Xio_fn -> Xin -> Xio (...) f g xin = f xin \\\ g }}} and in `X_interface` we get {{{ x_send_argL argL = x_send x_multi_arg_esc_seq ... x_send [toEnum (length argL)] ... app ( map x_send_arg argL ) ... x_send x_end_arg_esc_seq }}} It turns out that `...` gets w/w'd (because it is CPR'd in fact), and that means it doesn't inline until phase 0. If we inline in phase 2 we get lots of fold/build fusion, which leads to a whopping 25% improvement in the allocation of the veritas benchmark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 12:48:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 12:48:10 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.da976689a543d46e3598a74c800943f1@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I think comment:6 is a red herring. Why is GHC attempting to report about `~R#` at all here? The type of the hole is really `Coercible a b`. I don't think this is a pretty-printing issue. Instead, the solver needs to be taught somewhere to transmute `a ~R# b` constraints to `Coercible a b` constraints. But where? Do we do this for nominal equality anywhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 13:11:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 13:11:46 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.64257fbf3823ab323b8c45a0fb0883c1@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Instead, the solver needs to be taught somewhere to transmute a ~R# b constraints to Coercible a b constraints. But where? Do we do this for nominal equality anywhere? We do not transmute unsolved `a ~# b` constraints into `a ~ b`. Rather we ''pretty-print'' the unsolved `a ~# b` constraint as `a ~ b`. But if we do that ''and'' print the kind of the constraint, the two will be inconsistent. It appears that this only shows up for holes. Maybe we should refrain from printing the kind of a hole-filler if it's a constraint? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 13:32:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 13:32:43 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.440da5286bcad1656b2e1a3c1d1f90cd@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I like `Solo#` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 14:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 14:08:04 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.405ab899182abefc17934f97106d5666@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: 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): +1 on `Solo#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 14:29:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 14:29:25 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.9374468d51fa000c27a3ff57bd2f40fc@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14683 #14975 | Differential Rev(s): D4394 D4395 #14737 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2fbe0b5171fd5639845b630faccb9a0c3b564df7/ghc" 2fbe0b5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fbe0b5171fd5639845b630faccb9a0c3b564df7" Caching coercion roles in NthCo and coercionKindsRole refactoring While addressing nonlinear behavior related to coercion roles, particularly `NthCo`, we noticed that coercion roles are recalculated often even though they should be readily at hand already in most cases. This patch adds a `Role` to the `NthCo` constructor so that we can cache them rather than having to recalculate them on the fly. https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the approach. Performance improvement over GHC HEAD, when compiling Grammar.hs (see below): GHC 8.2.1: ``` ghc Grammar.hs 176.27s user 0.23s system 99% cpu 2:56.81 total ``` before patch (but with other optimizations applied): ``` ghc Grammar.hs -fforce-recomp 175.77s user 0.19s system 100% cpu 2:55.78 total ``` after: ``` ../../ghc/inplace/bin/ghc-stage2 Grammar.hs 10.32s user 0.17s system 98% cpu 10.678 total ``` Introduces the following regressions: - perf/compiler/parsing001 (possibly false positive) - perf/compiler/T9872 - perf/compiler/haddock.base Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11735 Differential Revision: https://phabricator.haskell.org/D4394 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 15:30:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 15:30:21 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.316599af342ad96de1401c67a5dbe90c@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Here is another case where `ScopedTypeVariables` are less powerful than one might expect. This works: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} type family F a where F Bool = Int data T a where MkT :: forall b a. b ~ F a => b -> T a foo :: T Bool -> () foo (MkT (_ :: Int)) = () }}} but the equivalent(?) formulation using `TypeFamilies` does not: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} class C b a | a -> b instance C Int Bool data T a where MkT :: forall b a. C b a => b -> T a foo :: T Bool -> () foo (MkT (_ :: Int)) = () }}} gives {{{ /tmp/Foo.hs:11:11: error: • Couldn't match expected type ‘b’ with actual type ‘Int’ ‘b’ is a rigid type variable bound by a pattern with constructor: MkT :: forall b a. C b a => b -> T a, in an equation for ‘foo’ at /tmp/Foo.hs:11:6-19 • When checking that the pattern signature: Int fits the type of its context: b In the pattern: _ :: Int In the pattern: MkT (_ :: Int) }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:08:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:08:13 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.b3c80b388537824063def094795bff0e@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8b10b8968f25589b1857f12788fc79b3b142c467/ghc" 8b10b896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b10b8968f25589b1857f12788fc79b3b142c467" Inline wrappers earlier This patch has a single significant change: strictness wrapper functions are inlined earlier, in phase 2 rather than phase 0. As shown by Trac #15056, this gives a better chance for RULEs to fire. Before this change, a function that would have inlined early without strictness analyss was instead inlining late. Result: applying "optimisation" made the program worse. This does not make too much difference in nofib, but I've stumbled over the problem more than once, so even a "no-change" result would be quite acceptable. Here are the headlines: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof -0.5% -0.5% +2.5% +2.5% 0.0% fulsom -1.0% +2.6% -0.1% -0.1% 0.0% mate -0.6% +2.4% -0.9% -0.9% 0.0% veritas -0.7% -23.2% 0.002 0.002 0.0% -------------------------------------------------------------------------------- Min -1.4% -23.2% -12.5% -15.3% 0.0% Max +0.6% +2.6% +4.4% +4.3% +19.0% Geometric Mean -0.7% -0.2% -1.4% -1.7% +0.2% * A worthwhile reduction in binary size. * Runtimes are not to be trusted much but look as if they are moving the right way. * A really big win in veritas, described in comment:1 of Trac #15056; more fusion rules fired. * I investigated the losses in 'mate' and 'fulsom'; see #15056. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:28:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:28:56 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.b6de0b0d0b7dbcd0a2c84f164f1c9556@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The `mate` regression was very delicate. In Move.moveDetailsFor, we inline {{{ bd = Board.rmPieceAt c_a25I sq_a2np bd_a25J }}} into two branches of a case (to hopefully avoid allocating it). I think this is postInlineUnconditionally. But then it is floated out and has to be laboriously CSE'd again! (Idea: this aggressive inlining could be done rather late, and perhaps be a late float-in pass. The only gain is less alloc.) However, more delicately we end up with this, where `rPA1` is short for `rmPieceAt1`: $j1 (rPA1 x) --inline-> let v = rPA1 in ...x...x.. $j2 (rPA1 x) --no inline-> $j2 (rPA1 x) In the first case `(rPA1 x)` gets `RhsCtxt`, and hence is inlined (not boring). But in the second, the context is boring, so not inlined. Then both these expressions are floated out, but they do not get CSEd togehter becuase they look different (one has been inlined and the other hasn't). So then we get {{{ lvl1 = ...x..x.. lvl2 = rPA1 x }}} And now the `rPA1 x` is in an `RhsCtxt` and hence is inlined, giving two identical expressions. But it's too late for CSE. (Indeed, CSE is done immediately after float-out, but before any simplification. All very delicate, and not the fault of this patch. Makes me wonder if we should should really distinguish between `BoringCtxt` and `RhsCtxt`. Idea: just try collapsing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:33:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:33:13 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.122a640d757a93bcc17dbb7035aae3d2@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The `fulsom` regression was in `Csg.calc`, which has nested join points. Several of them end up like this: {{{ join j (x :: Double) = Board (case x of { D# y -> ... }) ... in ....(j (D# v)).... }}} So the call to $j$ ends up with an explicit `(D# v)` argument, and `SpecConstr` should catch it. But alas it does not because this happens nestedly, and `SpecConstr` is worried about exponential blowup. Why is this a regression? Because something got inlined, that made a join point a bit bigger, which mean that the ''join point'' wasn't inlined. A classic inline-cascade problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:35:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:35:46 -0000 Subject: [GHC] #15069: Missed SpecConstr opportunity Message-ID: <046.6741d67554ec264c29f341c9cf201df7@haskell.org> #15069: Missed SpecConstr opportunity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you look at the final Core for `Csg.calc` in `nofib/real/fulsom` you'll see missed opportunities for `SpecConstr`. It has nested join points which look like this: {{{ join j (x :: Double) = Board (case x of { D# y -> ... }) ... in ....(j (D# v)).... }}} So the call to $j$ ends up with an explicit `(D# v)` argument, and `SpecConstr` should catch it. But alas it does not because this happends nestedly, and `SpecConstr` is worried about exponential blowup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:46:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:46:14 -0000 Subject: [GHC] #15070: postInlineUnconditionally is too eager Message-ID: <046.b22f22fb3bde11e0d92ca25a60587ce0@haskell.org> #15070: postInlineUnconditionally is too eager -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 `nofib/spectal/mate`, look at `Move.moveDetailsFor`. In this function we inline a local definition {{{ bd = Board.rmPieceAt c_a25I sq_a2np bd_a25J }}} into two branches of a case (to hopefully avoid allocating it). I think this is `postInlineUnconditionally`. But then it is floated out and has to be laboriously CSE'd again! Maybe `postInlineUnconditionally` should be less aggressive. To quote the comment: {{{ -- So the main target is things like -- let x = f y in -- case v of -- True -> case x of ... -- False -> case x of ... -- This is very important in practice; e.g. wheel-seive1 doubles -- in allocation if you miss this out }}} and {{{ -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot-spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} At least for the second of these cases, we could do the float-in/inlining very late in the compilation pipeline, not all the time. For the first, it's not so clear, but worth experimenting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 16:56:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 16:56:08 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.0df749a7138a36429729d51c6abe2620@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556, Wiki Page: | Phab:D4617 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D4556 => Phab:D4556, Phab:D4617 Comment: For the record, I have hacked together something along the lines of comment:10 in Phab:D4617. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:15:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:15:15 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.582dbfc8ee8c509b5d04a79860fc7dcd@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * milestone: 8.2.3 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:18:25 -0000 Subject: [GHC] #15071: :set usage in ghci tests breaks platform independence of output Message-ID: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> #15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance: {{{ --- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 +++ "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 @@ -7,7 +7,6 @@ GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fno-diagnostics-show-caret - -fexternal-dynamic-refs -fignore-optim-changes -fignore-hpc-changes -fno-ghci-history }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:20:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:20:19 -0000 Subject: [GHC] #15071: :set usage in ghci tests breaks platform independence of output In-Reply-To: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> References: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> Message-ID: <061.8ab98d10b52c0b3c84cfb773b2723549@haskell.org> #15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The affected tests are, {{{ ghci024 ghci057 T9293 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:29:15 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files Message-ID: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently `T14697` is disabled on Windows as that test produces a long enough command-line (mostly `-D` flags) that it runs amok of the Windows command-line length limit. It seems like the solution here will be to teach the testsuite driver to invoke GHC with a response file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:30:44 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files In-Reply-To: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> References: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> Message-ID: <061.62d86b7dc6c2dd6769e0fbc3b2aadc6c@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Test Suite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:10 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files In-Reply-To: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> References: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> Message-ID: <061.d11eae1cade18ea78be05884e6db024a@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:19 -0000 Subject: [GHC] #15071: :set usage in ghci tests breaks platform independence of output In-Reply-To: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> References: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> Message-ID: <061.c2cefd275440764ee433eeebb09060df@haskell.org> #15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:32 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.e9eb5c6fb3466f6c0e61380aa2869bdd@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:40 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.2bbfeaa434dd6c2f1cab526d38c0903f@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:48 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.b1212a4330a01b36d9923440e6c3c845@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:41:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:41:58 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.7acbf4cbc2ab7cb822aa60afdf578960@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:42:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:42:08 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 In-Reply-To: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> References: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> Message-ID: <061.ba5c3c5690bd52eb2ea97d6a7305380a@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------------- Changes (by bgamari): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:42:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:42:16 -0000 Subject: [GHC] #15059: ghcpkg05 fails In-Reply-To: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> References: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> Message-ID: <061.b29b03c06dd41356077205ba08bb468d@haskell.org> #15059: ghcpkg05 fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:42:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:42:27 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.1818246aa1706b62ec35f9ce1be3183f@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10037, #4012, | Differential Rev(s): #12935 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:44:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:44:49 -0000 Subject: [GHC] #14704: Spurious cost-centre test failures In-Reply-To: <046.aed78b7537a34d382c90181e0bd1ef41@haskell.org> References: <046.aed78b7537a34d382c90181e0bd1ef41@haskell.org> Message-ID: <061.0f87394ad61f240203af1281b7e4dd6d@haskell.org> #14704: Spurious cost-centre test failures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4351 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:45:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:45:12 -0000 Subject: [GHC] #14706: T11489 fails if run as root In-Reply-To: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> References: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> Message-ID: <061.b7d10d7b6642f8fcc62b5bf6d14d2b14@haskell.org> #14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mrkkrp Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.5 Integration | 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:D4360 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This is resolved as we now run the CI jobs under Docker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:46:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:46:22 -0000 Subject: [GHC] #14698: Cut STM release In-Reply-To: <046.c514496096a222bc1b6ef3f997b3783f@haskell.org> References: <046.c514496096a222bc1b6ef3f997b3783f@haskell.org> Message-ID: <061.c3df229dbffebb2fae4048ca9d608e63@haskell.org> #14698: Cut STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 17:55:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 17:55:05 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies Message-ID: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following compiles with both GHC 8.2.2 and 8.4.1: {{{#!hs newtype Drain = Drain { _drain :: Word8 } deriving stock (Eq, Ord, Show, Generic) deriving newtype (Storable) deriving anyclass (NFData) }}} However, adding `Prim` beside `Storable` in the `newtype` area yields the following with GHC 8.2.2: {{{ /home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error: • Illegal unboxed tuple type as function argument: (# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #) • In the expression: ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) primitive-0.6.3.0:Data.Primitive.Types.readByteArray# In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’: primitive-0.6.3.0:Data.Primitive.Types.readByteArray# = ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) }}} and this with GHC 8.4.1: {{{ Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeR ep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) Did you mean to enable TypeInType? | 1132 | deriving newtype (Storable, Prim) | }}} Turning on `TypeInType` as it suggests gives the same `Illegal unboxed tuple...` error. I've hand-written `Storable` instances before so I'm confident in its derivation, but I otherwise know nothing about `Prim`. Is there something magical about it that prevents it from being newtype derived in the same way? Thank you kindly, Colin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 18:21:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 18:21:07 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.00e27cd81e13e9a9e5699c7ec360f253@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Hmm, this is bad news. Presumably this is a due to a toolchain change which we should try to get ahead of since it will no doubt propagate to other distributions soon enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 18:58:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 18:58:53 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.7098b2af8dd0d7ec857ccc767aec0841@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving Comment: Indeed. The fix for #14579 requires generating code for `GeneralizeNewtypeDeriving` that has more explicit type/kinds signatures. The flipside is that `Prim`, whose types mention unboxed tuples and levity polymorphic kinds, now requires enabling `TypeInType` and `UnboxedTuples` to derive, as you've observed. There are a handful of language extensions that GHC always enables under the hood when deriving things (such as `KindSignatures`), but I'm very much doubtful that we'd want to always enable either `TypeInType` or `UnboxedTuples`, since those can cause some other programs to break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 19:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 19:01:23 -0000 Subject: [GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI In-Reply-To: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> References: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> Message-ID: <060.06e141e020c924a657355009301caf0b@haskell.org> #14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14705 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 19:26:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 19:26:43 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.3aec32a521fb79ff09746b6e3fbdebeb@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fosskers): Oh look at that - enabling `UnboxedTuples` on my end makes the error disappear, and I seem to be able to use the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 19:30:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 19:30:01 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.a316bdc3941229a23b554da8018db69f@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, now I see why you were confused—the `Illegal unboxed tuple type as function argument` error message doesn't recommend enabling `UnboxedTuples`. Would you consider this issue resolved if the error message were revised to do so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 19:45:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 19:45:47 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.1580be5aad3d5706780b86608b9054c9@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fosskers): I would, yeah. I've never used `UnboxedTuples` before (but had heard of them once reminded), so it didn't even occur to me that all I was missing was a `LANGUAGE` extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 20:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 20:24:20 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.f4c2796127de58bf9ccf17f3b858bf01@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 20:31:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 20:31:54 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.9b46944d62fd08feec6fa4c6ca3a8a08@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620 Wiki Page: | -------------------------------------+------------------------------------- Comment (by fosskers): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:04:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:04:33 -0000 Subject: [GHC] #15045: Remove broken top-level shell.nix In-Reply-To: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> References: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> Message-ID: <064.aef571a86a4704ed7b55327d2fced7f8@haskell.org> #15045: Remove broken top-level shell.nix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Phab:D4599 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"430e6fedfda3e705c6e4c962954c32211a90f9f7/ghc" 430e6fed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="430e6fedfda3e705c6e4c962954c32211a90f9f7" Remove broken top-level shell.nix There is a maintained shell.nix file in the hadrian submodule. This has long since been broken anyway. Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15045 Differential Revision: https://phabricator.haskell.org/D4599 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:04:50 -0000 Subject: [GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect In-Reply-To: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> References: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> Message-ID: <064.b15d64b959da31e8b27947d0f77fcb7e@haskell.org> #15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 Ben Gamari ): In [changeset:"698db813dbc49f6c1e011299e8044b3bafb26847/ghc" 698db813/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="698db813dbc49f6c1e011299e8044b3bafb26847" Fix implementation of rnIfaceBndr Reviewers: ezyang, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15041 Differential Revision: https://phabricator.haskell.org/D4600 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:05:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:05:06 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.378df00c58b9777d264461be35bd70dd@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Azel Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: unicode, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4593 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"da7438526e4bfb1821aa77a22ff66a4a80baf8c6/ghc" da74385/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da7438526e4bfb1821aa77a22ff66a4a80baf8c6" base: Add a test for T10412 Expects the current behavior, will be updated by D4593 to reflect desired behavior. Reviewers: hvr Subscribers: thomie, carter GHC Trac Issues: #10412 Differential Revision: https://phabricator.haskell.org/D4610 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:05:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:05:24 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.d9ae532fcd728c29866500ee4caddfb1@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2a5bdd9adb1cb4afecd3303f0cfcc224be5ce745/ghc" 2a5bdd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2a5bdd9adb1cb4afecd3303f0cfcc224be5ce745" Remove unnecessary check in simplCast The coercion optimizer will take care of it anyway, and the check is prohibitively expensive. See Trac #14737. Reviewers: bgamari Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D4568 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:05:43 -0000 Subject: [GHC] #15045: Remove broken top-level shell.nix In-Reply-To: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> References: <049.cbe922969897c94e59b0dd80b11db65c@haskell.org> Message-ID: <064.76c83d6e2b133f0a4bd6dc703dcd4316@haskell.org> #15045: Remove broken top-level shell.nix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4599 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:05:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:05:45 -0000 Subject: [GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect In-Reply-To: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> References: <049.3109210c4d77ea072ed6e0c3eaa212d1@haskell.org> Message-ID: <064.d665380973581cd3895f693d541201ec@haskell.org> #15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:15:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:15:55 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.4c1a76de42aad0ad92c1f3b4d4af6245@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: | UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13276 | Differential Rev(s): Phab:D4622, Wiki Page: | Phab:D4623 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4622, Phab:D4623 Comment: Whoops! See Phab:D4622 and Phab:D4623. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:18:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:18:48 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.f01039cdd456c5b04b2f7b044c4ecefe@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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): Phab:D4621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => Phab:D4621 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:28:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:28:53 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c Message-ID: <042.d5f176850225992392f8f3098794a0ab@haskell.org> #15074: Possible uninitialised values in ffi64.c --------------------------------------+--------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Running the clang static analyser when building ghc HEAD throws up 3 possible errors in x86/ffi64.c initialisation / out-of-bounds errors, shown in the attached annotated files showing how they could occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:29:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:29:50 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.1d8498dd9c7686fcd1ef401e9780a486@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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: | -----------------------------------+-------------------------------------- Changes (by jrp): * Attachment "1_src_x86_ffi64.c.html" added. Clang Analyse output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:30:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:30:04 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.6913e0742d352c74838b030984716cba@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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: | -----------------------------------+-------------------------------------- Changes (by jrp): * Attachment "2_src_x86_ffi64.c.html" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 20 22:30:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Apr 2018 22:30:20 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.423a47d812f979be95a6f8883c675a87@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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: | -----------------------------------+-------------------------------------- Changes (by jrp): * Attachment "3_src_x86_ffi64.c.html" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 00:30:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 00:30:51 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.d44735dfe1f37f274bb9e4dcce9491a6@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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 bgamari): I believe this file is actually from libffi. Do you think you could report this upstream (https://github.com/libffi/libffi/issues)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 10:47:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 10:47:41 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.738e32d8ee56eae375f16efff7e6bb3c@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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 jrp): Thanks. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 11:11:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 11:11:46 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.196a48ff9117f7d7d11ee23d27b16fd7@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): By the way, the ghc available on Ubuntu is only 8.0.2-11 (which means that it cannot build HEAD). The haskell platform package is from 2014. LLVM is 6, so you also need to install 5 to get LLVM builds, although I seem that there is some testing going on to update support #15024 That was tested against 8.4.1. I got more errors on HEAD and did not pursue further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 11:36:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 11:36:29 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.adb6a0e3599556769d5280626f198745@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): As far as Ubuntu concerned, ''the'' way to use reasonable version of modern GHC is [https://launchpad.net/~hvr/+archive/ubuntu/ghc hvr's ppa], so I wouldn't bother about official repo's version too much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 12:52:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 12:52:39 -0000 Subject: [GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples In-Reply-To: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> References: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> Message-ID: <060.b571ce8e72fad75639367dfb30c143d7@haskell.org> #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I'm also interested in seeing this officially supported. For reference, David describes an application of this in further detail here: https://github.com/tibbe/unordered-containers/pull/188. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 14:46:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 14:46:03 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.1d421277b4bfa962f0297f00c1579bb8@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * testcase: => deSugar/should_compile/T14547 * status: new => patch * differential: => Phab:D4624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 17:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 17:33:34 -0000 Subject: [GHC] #15075: Sometimes '-optl-optl' used for linker options instead of just '-optl' Message-ID: <045.174e43a805b71e2590ba4cd6ded18a9b@haskell.org> #15075: Sometimes '-optl-optl' used for linker options instead of just '-optl' -------------------------------------+------------------------------------- Reporter: jwhite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13091 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The build system does not construct some linker options correctly. For some options it doubles the `-optl` switch, resulting in options like {{{ -optl-optl-Wl,-arch -optl-optl-Wl,x86_64 }}} being passed to GHC, instead of {{{ -optl-Wl,-arch -optl-Wl,x86_64 }}} Root cause: in `rules/distdir-way-opts.mk`, `$1_$2_$3_ALL_LD_OPTS` is constructed with {{{ # Options for passing to gcc for linking $1_$2_$3_ALL_LD_OPTS = \ ... \ $$(foreach o,$$(EXTRA_LD_LINKER_OPTS),-optl-Wl$$(comma)$$o) \ $$(foreach o,$$(CONF_LD_LINKER_OPTS_STAGE$4),-optl-Wl$$(comma)$$o) }}} Which is then used in {{{ # Options for passing to GHC when we use it for linking $1_$2_$3_GHC_LD_OPTS = \ $$(addprefix -optl, $$($1_$2_$3_ALL_LD_OPTS)) \ $$($1_$2_$3_MOST_HC_OPTS) }}} The `-optl` in the foreach invocations in `$1_$2_$3_ALL_LD_OPTS` is not necessary, it is handled already by the addprefix call in `$1_$2_$3_GHC_LD_OPTS`. Example link command line generated by the the build system, showing the problem: {{{ "${HOME}/.stack/programs/x86_64-osx/ghc-7.10.3/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25 -package-id containers-0.5.6.2-68e3ece8a4f91a31e327fe89f8052a53 -package-id directory-1.2.2.0-3b3e1a8d629ccaa6c4588a9bb46bb163 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-a1a69425f3f6c11a82785be7baab3b68 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-optl-Wl,-arch -optl-optl-Wl,x86_64 -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25 -package-id containers-0.5.6.2-68e3ece8a4f91a31e327fe89f8052a53 -package-id directory-1.2.2.0-3b3e1a8d629ccaa6c4588a9bb46bb163 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-a1a69425f3f6c11a82785be7baab3b68 -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o }}} It affects all operating systems as far as I can tell, but only seems to cause a build failure on Solaris, see #13091. Looks like this was introduced in commit [https://phabricator.haskell.org/rGHC87c3b1d4395c3d4fc7a5272717c48f3f525da959 87c3b1d], in release 8.2.1, backported to 8.0.2 in commit [https://phabricator.haskell.org/rGHCc5f375c53671130c79713800b13a1da53d070b84 c5f375c]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 17:38:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 17:38:15 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.b9a4bac1c87f578e1008d7d417d2a605@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jrp): * Attachment "testsuite_summary.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 17:39:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 17:39:01 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.835df7da24fd0ac4740d7b3c55a414a8@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): OK. Thanks. I failed to spot that in the documentation here. I've also run a "slow" test from the current HEAD. This throws up many more test suite failures, probably because I didn't install Haddock, or various libraries. The summary is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 18:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 18:01:48 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.480397846d413f413875f1af57bc5269@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Seems that the solution is to prevent ghc from getting stuck in a loop. Since this is a longstanding bug, i guess it's difficult to fix. Alternatively .. could there perhaps be some detection that it's stuck in a loop and a message what part of the code is causing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 18:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 18:31:11 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.7a171aa1ea921342f000786df62b3d80@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jwhite): The immediate cause is the bug described in #15075. When that bug is fixed, the build still fails on `hsc2hs`: {{{ "/opt/local/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP- include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-7097b6a59941ac1c7cd21845d2bb489f -package-id containers-0.5.6.2-312177b9402c9bc329c058bf8e768a8c -package-id directory-1.2.2.0-78f4e60e387a622bced41832df453a58 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-5572f0ea7a5798559ac3d63d002bf1d4 -XHaskell2010 -no-user- package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-Wl,-m64 -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide- all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-7097b6a59941ac1c7cd21845d2bb489f -package-id containers-0.5.6.2-312177b9402c9bc329c058bf8e768a8c -package-id directory-1.2.2.0-78f4e60e387a622bced41832df453a58 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-5572f0ea7a5798559ac3d63d002bf1d4 -XHaskell2010 -no-user- package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o ghc: fd:12: hGetContents: does not exist (No such file or directory) utils/hsc2hs/ghc.mk:15: recipe for target 'utils/hsc2hs/dist/build/tmp/hsc2hs' failed make[1]: *** [utils/hsc2hs/dist/build/tmp/hsc2hs] Error 2 make[1]: *** Deleting file 'utils/hsc2hs/dist/build/tmp/hsc2hs' Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 }}} Note on the command line `-optl-Wl,-m64`. The Solaris linker does not support an `-m64` option. It should be `-64` instead. After fixing that, the build proceeds, and eventually completes. The following diff fixes it, after `autoreconf && ./configure`: {{{ diff --git a/aclocal.m4 b/aclocal.m4 index 7723743..fcf3a47 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -560,7 +560,7 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], x86_64-unknown-solaris2) $2="$$2 -m64" $3="$$3 -m64" - $4="$$4 -m64" + $4="$$4 -64" $5="$$5 -m64" ;; alpha-*) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 20:16:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 20:16:30 -0000 Subject: [GHC] #15074: Possible uninitialised values in ffi64.c In-Reply-To: <042.d5f176850225992392f8f3098794a0ab@haskell.org> References: <042.d5f176850225992392f8f3098794a0ab@haskell.org> Message-ID: <057.f36542117b03a2ed817ed18237845453@haskell.org> #15074: Possible uninitialised values in ffi64.c -----------------------------------+-------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 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: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 20:22:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 20:22:46 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.c8701cdfb5f8e2719e25189bcf980ca5@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Presumably the `-m64` flag is assuming that the user will be using a gnu toolchain on Solaris. It seems like we should try to avoid breaking this possibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 21 20:22:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Apr 2018 20:22:59 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.c1489a124a76d3af81f6273958327166@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 06:41:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 06:41:33 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.a9c8c3d34a967f30a796b34444a31d2e@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jwhite): Yes, I suppose I should have said "fixes it for me". For more context, I'm building on SmartOS on a `base64 14.3.0` image (which is a bit old), and it has no toolchain installed by default, just the system linker in `/usr/bin/ld`. The toolchain I am using is gcc 4.7, installed from the pkgsrc package `gcc47-4.7.3nb6`. The compiler is installed as `/opt/local/bin/gcc` and the linker as `/opt/local/bin/gld`. I guess that's why `./configure` is picking up `/usr/bin/ld`. The bootstrap GHC is 7.10.3, itself bootstrapped from GHC 7.6.3 from pkgsrc package `ghc-7.6.3nb4`, both using `/usr/bin/ld`. Also, even though binutils is installed (pkgsrc `binutils-2.24nb3`), gcc is using `/usr/bin/ld`, not `/opt/local/bin/gld`: {{{ $ truss -af -t execve /opt/local/bin/gcc -o main main.c ... 74127: execve("/usr/bin/ld", 0x00470C20, 0x0046B1D0) argc = 28 74127: argv: /usr/bin/ld -R/opt/local/lib/ -Y 74127: P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o main 74127: /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o 74127: /usr/lib/amd64/values-Xa.o 74127: /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/crtbegin.o 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib/amd64 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 74127: -L/lib/amd64 -L/usr/lib/amd64 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../.. 74127: -R/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64 74127: -R/opt/local/gcc47/lib/amd64 /var/tmp//ccPDaWlK.o -lgcc 74127: -lgcc_eh -lc -lgcc -lgcc_eh 74127: /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/crtend.o 74127: /usr/lib/amd64/crtn.o 74127: execve("/usr/bin/amd64/ld", 0x08047578, 0x080475EC) argc = 28 74127: argv: /usr/bin/ld -R/opt/local/lib/ -Y 74127: P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o main 74127: /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o 74127: /usr/lib/amd64/values-Xa.o 74127: /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/crtbegin.o 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib/amd64 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 74127: -L/lib/amd64 -L/usr/lib/amd64 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib 74127: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../.. 74127: -R/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64 74127: -R/opt/local/gcc47/lib/amd64 /var/tmp//ccPDaWlK.o -lgcc 74127: -lgcc_eh -lc -lgcc -lgcc_eh 74127: /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/crtend.o 74127: /usr/lib/amd64/crtn.o 74125: Received signal #18, SIGCLD, in waitid() [default] 74125: siginfo: SIGCLD CLD_EXITED pid=74127 status=0x0000 74104: Received signal #18, SIGCLD, in waitid() [default] 74104: siginfo: SIGCLD CLD_EXITED pid=74125 status=0x0000 }}} So I don't think I'm in a position to test that right now (rebuilding all those toolchains on top of GNU binutils would take a very long time, I'm running this on a very slow VM). Regardless, I'm not sure `-m64` would be right here for GNU ld either. `-m` takes an `emulation` argument, and the valid values are given by {{{ $ ld -V GNU ld (GNU Binutils)2.24 Supported emulations: elf_x86_64_sol2 elf_x86_64 elf_i386_sol2 elf_i386_ldso elf_i386 elf_l1om elf_k1om }}} Maybe one of the first two is what's needed? Or perhaps it can just be omitted for GNU ld? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 06:45:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 06:45:26 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.fa65390d1ac7e3724003fc0b8ebc535a@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jwhite): * related: => #15075 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 08:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 08:14:08 -0000 Subject: [GHC] #5400: GHC loops on compiling with optimizations In-Reply-To: <047.a27358726060a61711801a78e0d6259d@haskell.org> References: <047.a27358726060a61711801a78e0d6259d@haskell.org> Message-ID: <062.20236447ca486fe500c895b9df6d74a1@haskell.org> #5400: GHC loops on compiling with optimizations -------------------------------------+------------------------------------- Reporter: noschinl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that the reproduction lacks a `{-# LANGUAGE ConstrainedClassMethods #-}` to compile with GHC 8.2.1 and then compiles flawlessly with -O2. The typical Russel's paradox example from the user's guide just crashes with a panic (similar to #5448): {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone russel To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6361 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} I'd advocate this to be a warning rather than a panic, but otherwise consider the whole issue fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 08:14:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 08:14:55 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.32abc341f1273179be8d18a2609320a1@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Actually, this doesn't reproduce anymore, at least not in the way described. For GHC 8.2.1, the original ghcloop.hs elicits the following panic: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying RuleFired Class op funcEq To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 15160 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} That's better than looping forever, although I don't know why it's a panic rather than a warning. Note that it also includes which function was the culprit. I read somewhere that the Simplifier adopted its fuel-based approach in the meantime, which may be the reason this is 'fixed'. The contravariant example doesn't reproduce at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 08:15:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 08:15:36 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.bb55340fef30bda654a734bfdc143fe4@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #3872 #5400 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 08:17:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 08:17:09 -0000 Subject: [GHC] #3872: New way to make the simplifier diverge In-Reply-To: <046.1b2e753f6779610f3b007d619b3ca555@haskell.org> References: <046.1b2e753f6779610f3b007d619b3ca555@haskell.org> Message-ID: <061.ee86e1801f7ba62483859157f2e09a80@haskell.org> #3872: New way to make the simplifier diverge -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5400 #5448 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #5400 #5448 Comment: This doesn't loop infinitely anymore with GHC 8.2.1 and instead panics: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone rir_s1bm To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 11721 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} I think this should result in a warning rather than in a crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 11:16:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 11:16:42 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.2b687d101d0c147fb2b686c3fa21e5ba@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): sgraf do you know where i can see this bug current status? When i search on this page i don't find "fixed" apart from your comment. What would be interesting is to test all the test cases (found in related bugs) with the last version of GHC 8.4.* I think this Panic is very helpful. It could be further improved to give some tips on how the code can be rewritten to have it compiled correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:00:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:00:19 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.7bce95371d4d0ae61733d685b5f0efd0@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): Replying to [comment:25 RyanGlScott]: > Great! Do you consider this issue to be resolved, then? Yes, please close it. I will update `derive-topdown` a bit when I have time. After that I will have a look [https://ghc.haskell.org/trac/ghc/ticket/13368] and try to make it possible with `derive-topdown`. I suppose that we could write an essay or paper to summarize all this deriving stuffs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:03:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:03:52 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.73f18b6e9e424935b85f9efd9e51faaf@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by songzh): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:11:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:11:23 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.a2cc1ea05422895490099b45b3359b0b@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here is a much simpler way to trigger the panic in comment:2: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (forall t. Proxy t -> Proxy (f t)) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Cb[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} But it now appears that this bug is of a different nature than the original program. I'll close this ticket in favor of a new one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:18:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:18:29 -0000 Subject: [GHC] #15076: Typed hole causes GHC to panic (No skolem info) Message-ID: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> #15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypedHoles, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14040 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (forall t. Proxy t -> Proxy (f t)) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Cb[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:20:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:20:01 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.d80a5de24426d512cf68e2276bae38c1@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => partial-sigs/should_fail/T14040a * status: new => closed * resolution: => fixed * related: #13877 => #13877, #15076 * milestone: => 8.6.1 Comment: Closing in favor of #15076. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:22:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:22:46 -0000 Subject: [GHC] #15076: Typed hole causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.a9f1f10f6dce83d56c314cc40ac42069@haskell.org> #15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Echoing simonpj's comments in https://ghc.haskell.org/trac/ghc/ticket/14040#comment:7, we can see from `-ddump-tc-trace` that: {{{ reportUnsolved (after zonking): Free tyvars: (t_a1TL[tau:2] :: Proxy x_a1TC[sk:2]) a_a1Sj[sk:1] Tidy env: ([ESf9Q :-> 1, ESfa3 :-> 1, ESfWb :-> 2, ESgJA :-> 1], [a1Sj :-> a1_a1Sj[sk:1], a1TC :-> x_a1TC[sk:2], a1TD :-> a_a1TD[sk:2], a1TL :-> t0_a1TL[tau:2]]) Wanted: WC {wc_impl = Implic { TcLevel = 2 Skolems = (x_a1TC[sk:2] :: a_a1Sj[sk:1]) a_a1TD[sk:2] (f_a1TE[sk:2] :: forall (x :: a_a1TD[sk:2]). Proxy x -> *) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [D] _ {0}:: Proxy t_a1TL[tau:2] -> Proxy (f_a1TE[sk:2] x_a1TC[sk:2] t_a1TL[tau:2]) (CHoleCan: TypeHole(_))} Binds = EvBindsVar Needed inner = [] Needed outer = [] the type signature for: foo :: forall (x :: a_a1Sj[sk:1]) a (f :: forall (x :: a). Proxy x -> *). S (f x) -> () }} ... Adding error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Sj[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} Here, `a1_a1Sj` is not bound by any implication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:29:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:29:52 -0000 Subject: [GHC] #15076: Typed hole causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.8689a00c0ab1cb78bebd3f6ddfce3a5e@haskell.org> #15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, > which was different enough from the original program in #14040 to warrant > its own ticket. The following program panics on every version of GHC from > 8.0.2 onward: > > {{{#!hs > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeInType #-} > module Bug where > > import Data.Kind > import Data.Proxy > > newtype S (f :: k1 -> k2) > = MkS (forall t. Proxy t -> Proxy (f t)) > > foo :: forall (a :: Type) > (f :: forall (x :: a). Proxy x -> Type). > S f -> () > foo (MkS (sF :: _)) = () > }}} > {{{ > $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs > GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.5.20180420 for x86_64-unknown-linux): > No skolem info: > [a1_a1Cb[sk:1]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in > ghc:Outputable > pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in > ghc:TcErrors > }}} New description: Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (Proxy f) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:14:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a_a1Ca[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:38:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:38:43 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check (was: Explicitly quantifying a kind variable causes a type family to fail to typecheck) In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.cf005f96166db83dc57bcc973174cfff@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies, TypeInType => TypeInType Comment: As it turns out, this is not at all specific to type families. The same phenomenon occurs in data types: {{{#!hs data Foo1 (e :: Proxy (a :: k)) :: Type -- typechecks data Foo2 (k :: Type) (e :: Proxy (a :: k)) :: Type -- doesn't typecheck }}} Or even plain old functions: {{{#!hs foo1 :: forall (e :: Proxy (a :: k)). Int -- typechecks foo1 = 42 foo2 :: forall (k :: Type) (e :: Proxy (a :: k)). Int -- doesn't typecheck foo2 = 42 }}} So I'm guessing that any type variable telescope suffers from this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:50:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:50:12 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.b9e267d314570f4f4e571ac074348221@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 14268 Comment: Note that data family instances //will// gain `TyVarBndr`s once #14268 is implemented, so let's wait until that is done before coming back to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 14:52:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 14:52:09 -0000 Subject: [GHC] #13809: TH-reified type family and data family instances have a paucity of kinds In-Reply-To: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> References: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> Message-ID: <065.1d976454f69cbc0157f9e952e2ae0051@haskell.org> #13809: TH-reified type family and data family instances have a paucity of kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #8953, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 14268 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 16:00:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 16:00:10 -0000 Subject: [GHC] #15077: Suggest NoMonomorphismRestriction or type signature Message-ID: <051.0470f8288f64537291591ba13c0eb158@haskell.org> #15077: Suggest NoMonomorphismRestriction or type signature -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program results in a compile error. To fix the error one can either give an explicit signature or turn on `NoMonomorphismRestriction`. Could the compile error please mention both of these options (and provide the exact type signature required)? {{{ type family G a b data D a = D (G a ()) d = D () }}} {{{ • Couldn't match expected type ‘G a0 ()’ with actual type ‘()’ The type variable ‘a0’ is ambiguous • In the first argument of ‘D’, namely ‘()’ In the expression: D () In an equation for ‘d’: d = D () • Relevant bindings include d :: D a0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 18:07:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 18:07:14 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) (was: Typed hole causes GHC to panic (No skolem info)) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.ab7e94f0e3f1f7427fe5ff95a06e5025@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, > which was different enough from the original program in #14040 to warrant > its own ticket. The following program panics on every version of GHC from > 8.0.2 onward: > > {{{#!hs > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeInType #-} > module Bug where > > import Data.Kind > import Data.Proxy > > newtype S (f :: k1 -> k2) = MkS (Proxy f) > > foo :: forall (a :: Type) > (f :: forall (x :: a). Proxy x -> Type). > S f -> () > foo (MkS (sF :: _)) = () > }}} > {{{ > $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs > GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > Bug.hs:14:17: error:ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.5.20180420 for x86_64-unknown-linux): > No skolem info: > [a_a1Ca[sk:1]] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in > ghc:Outputable > pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in > ghc:TcErrors > }}} New description: Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). Proxy f -> () foo (_ :: _) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:11: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a_aZo[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 18:33:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 18:33:27 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.45cc09d2a4a34239e0462eb03e30927f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15076 Comment: I think that this ticket and #15076 share a symptom in common. This claim is based on the fact that slightly tweaking the program in comment:6 / comment:7 : {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data Foo (x :: Type) :: forall (a :: x). Proxy a -> Type quux :: forall arg. Proxy (Foo arg) -> () quux (_ :: _) = () }}} Yields: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:12: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [arg_aZr[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} Which is the same panic as in #15076. Plus, if you run this program with `-ddump-tc-trace`, you see: {{{ reportUnsolved (after zonking): Free tyvars: arg_aZr[sk:1] Tidy env: ([ESf71 :-> 1], [aZr :-> arg_aZr[sk:1]]) Wanted: WC {wc_impl = Implic { TcLevel = 2 Skolems = (a_a1p8[sk:2] :: arg_aZr[sk:1]) arg_a1p9[sk:2] No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [D] _ {0}:: Proxy (Foo arg_a1p9[sk:2] a_a1p8[sk:2]) (CHoleCan: TypeHole(_))} Binds = EvBindsVar Needed inner = [] Needed outer = [] the type signature for: quux :: forall (a :: arg_aZr[sk:1]) arg. Proxy (Foo arg a) -> () }} }}} Just like in #15076, `arg_aZr` is not bound in any implication. On the other hand, there is another type variable, `arg_a1p9`, that is suspiciously similar. Moreover, the type signature it gives for `quux`: {{{ quux :: forall (a :: arg_aZr[sk:1]) arg. Proxy (Foo arg a) -> () }}} Seems to have //two// different copies of `arg`! This is especially interesting in light of comment:3, where simonpj discovered that the existentially quantified tyvars in `MkBar` were screwed up, leading to two copies of `arg`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 18:33:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 18:33:52 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.c0e06bc093340b73078c8e89de0d5ff4@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14040 => #14040, #14880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 20:07:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 20:07:34 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.a75bbeb53f2356e1a6f84c4e910ffd6a@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This ticket isn't marked as fixed and I'm not sure if others would consider it fixed (a compiler should never reject a program because of an optimization pass). That's why I put fixed in quotes above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 22 21:25:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Apr 2018 21:25:19 -0000 Subject: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations In-Reply-To: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> References: <046.cf6aa1f222a474d575aee885f1a4c9dc@haskell.org> Message-ID: <061.5ea6cd41be4eb8f0d1db7fed5222f244@haskell.org> #5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:5 make it panic (with a helpful message) rather than looping. So that's an improvement. Better still would be to avoid looping or running out of fuel. But I have no idea how to do that. A modest improvement would be to produce a more civilised halt rather than a panic. But I don't think it's trivial to do so, and it's cosmetic so perhaps not that important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 01:04:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 01:04:46 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented Message-ID: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 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: -------------------------------------+------------------------------------- As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. Here's a first draft of what I have in mind for `Float`'s `Eq` and `Ord` instances: {{{ -- | Note that in the presence of @NaN@, this instance does not satisfy -- reflexivity: -- -- >>> nan = 0/0 :: Float -- >>> nan == nan -- False -- -- Also note that this instance does not encode structural equality: -- -- >>> 0 == (-0 :: Float) -- True -- >>> recip 0 == recip (-0 :: Float) -- False instance Eq Float where (==) = eqFloat }}} {{{ -- | Due to the peculiarities of @NaN@, this instance does not satisfy totality: -- -- >>> nan = 0/0 :: Float -- >>> nan <= nan -- False -- -- Another special case with @NaN@ is: -- -- @ -- 'compare' x y -- | 'isNaN' x || 'isNaN' y = 'GT' -- @ -- -- However -- -- @ -- nan > _ = False -- _ > nan = False -- @ -- -- In consequence we also have: -- -- @ -- 'max' x y | 'isNaN' x || 'isNaN' y = x -- 'min' x y | 'isNaN' x || 'isNaN' y = y -- @ -- -- Ignoring @NaN@, @Infinity@ and @-Infinity@ are the respective greatest -- and least elements of 'Float'. instance Ord Float where (F# x) `compare` (F# y) = if isTrue# (x `ltFloat#` y) then LT else if isTrue# (x `eqFloat#` y) then EQ else GT (F# x) < (F# y) = isTrue# (x `ltFloat#` y) (F# x) <= (F# y) = isTrue# (x `leFloat#` y) (F# x) >= (F# y) = isTrue# (x `geFloat#` y) (F# x) > (F# y) = isTrue# (x `gtFloat#` y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 04:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 04:01:37 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.8d75a7f324eb19cd7f5ab3da1d5f94b3@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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 dfeuer): That's perfectly documentation that Haddock will, sadly, chew up and turn into something almost completely unreadable. Ryan Scott thinks it's good to write documentation like that to drive Haddock development, but I'm not sure. As for what the customary laws ''are'', here's a rough draft: == `Eq` `Eq` is expected to be an equivalence relation, and values that compare "equal" should be indistinguishable (except perhaps when using an "private" interface). Reflexivity:: `x == x = True` Symmetry:: `x == y = y == x` Transitivity:: If `x == y && y == z = True`, then `x == z = True` Substitutivity:: If `x == y = True` and `f` is a "public" function, then `f x == f y = True` Negation:: `x /= y = not (x == y)` == `Ord` === Basics Transitivity:: If `x <= y && y <= z = True`, then `x <= z = True` Reflexivity:: relative to `==`: = True` Antisymmetry:: If `x <= y && y <= x = True`, then `x == y = True` === Operator interactions 1. `x >= y = y <= x` 2. `x < y = x <= y && x /= y` 3. `x > y = y < x` 4. `x < y = compare x y == LT` 5. `x > y = compare x y == GT` 6. `x == y = compare x y == EQ` The `max` and `min` rules look a bit funny. Note that `max x y` needn't be ''identical'' to either `x` or `y`; it just needs to ''look'' the same. 7. `min x y == if x <= y then x else y = True` 8. `max x y == if x >= y then x else y = True` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 04:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 04:02:15 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.807918f6d2e44b53af28a11cd504bbb2@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 10:08:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 10:08:33 -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.90c425f89d16b2a4e74956a23e87c8ac@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 ulysses4ever): * cc: ulysses4ever (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 16:20:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 16:20:43 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.fa38df2922822f6bd4e78ffb2a224e5b@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If you don't use a typed hole: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). Proxy f -> () foo _ = () }}} Then it compiles. However, it fails with a Core Lint error: {{{ $ /opt/ghc/8.4.2/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the type ‘forall (x :: a) a (f :: forall (x :: a). Proxy x -> *). Proxy (f x) -> ()’ @ a_aZi[sk:1] is out of scope *** Offending Program *** foo :: forall (x :: a) a (f :: forall (x :: a). Proxy x -> *). Proxy (f x) -> () [LclIdX] foo = \ (@ (x_a1e5 :: a_aZi[sk:1])) (@ a_a1e6) (@ (f_a1e7 :: forall (x :: a). Proxy x -> *)) _ [Occ=Dead] -> () $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Bug"#) *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 16:29:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 16:29:47 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.13913890df961f4e99ff372d69b9f9e6@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Similar shenanigans: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> data F λ> data F λ> _ :1:1: error: GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 17:03:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 17:03:44 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.78bdbbb443823708bdf966b4a72b6a1e@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"f04ac4d4d0811f48c68fecacefb262039ee33239/ghc" f04ac4d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f04ac4d4d0811f48c68fecacefb262039ee33239" Add testcase for #15050 so that we notice if someone accidentially implements this... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 17:07:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 17:07:37 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.edf2af46a28be5714dc7780609e644bb@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I can get the example from the original ticket to work simply by using `TauTv` instead of `SigTv`. But I’m sure that breaks stuff – in particular since `SigTv` are also used for type-checking (see faec8d358985e5d0bf363bd96f23fe76c9e281f7 and 8361b2c5a9f7a00f0024f44a43b851998ae41e33) – maybe a separate `KindTv` would be cleaner? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 17:39:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 17:39:19 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.78e33d05f0f3f22d1eb4d51b9655498e@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): An experimental implementation of this is in `wip/T15050`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 20:38:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 20:38:25 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.d17bf87eb4bbd55f9df55fa82ebccced@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: jme Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2031, Wiki Page: | Phab:D4627 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D2031 => Phab:D2031, Phab:D4627 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 23 23:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Apr 2018 23:21:46 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind Message-ID: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.2.2 and 8.4.2: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Void infixl 4 :== -- | Heterogeneous Leibnizian equality. newtype (a :: j) :== (b :: k) = HRefl { hsubst :: forall (c :: forall (i :: Type). i -> Type). c a -> c b } newtype Coerce a = Coerce { uncoerce :: Starify a } type family Starify (a :: k) :: Type where Starify (a :: Type) = a Starify _ = Void coerce :: a :== b -> a -> b coerce f = uncoerce . hsubst f . Coerce }}} But GHC HEAD rejects it: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:21:34: error: • Kind mismatch: cannot unify (c0 :: forall i. i -> *) with: Coerce :: forall k. k -> * Their kinds differ. Expected type: a -> c0 * a Actual type: Starify a -> Coerce a • In the second argument of ‘(.)’, namely ‘Coerce’ In the second argument of ‘(.)’, namely ‘hsubst f . Coerce’ In the expression: uncoerce . hsubst f . Coerce | 21 | coerce f = uncoerce . hsubst f . Coerce | ^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 00:53:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 00:53:37 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.9bf45ca67e163aa86f7fde70bdbadb11@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: This regression was introduced in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 01:35:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 01:35:16 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.90d7b59d140559769c43ce71e5d75142@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A more complicated example that also typechecks in 8.2.2 and 8.4.2, but not in GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import qualified Data.Type.Equality as Eq import GHC.Exts (Any) infixl 4 :== -- | Heterogeneous Leibnizian equality. newtype (a :: j) :== (b :: k) = HRefl { hsubst :: forall (c :: forall (i :: Type). i -> Type). c a -> c b } newtype Flay :: (forall (i :: Type). i -> i -> Type) -> forall (j :: Type). j -> forall (k :: Type). k -> Type where Flay :: forall (p :: forall (i :: Type). i -> i -> Type) (j :: Type) (k :: Type) (a :: j) (b :: k). { unflay :: p a (MassageKind j b) } -> Flay p a b type family MassageKind (j :: Type) (a :: k) :: j where MassageKind j (a :: j) = a MassageKind _ _ = Any fromLeibniz :: forall a b. a :== b -> a Eq.:~: b fromLeibniz f = unflay $ hsubst f $ Flay Eq.Refl }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:29:42: error: • Kind mismatch: cannot unify (p0 :: forall i. i -> i -> *) with: (Eq.:~:) :: forall k. k -> k -> * Their kinds differ. Expected type: p0 k a (MassageKind k a) Actual type: a Eq.:~: a • In the first argument of ‘Flay’, namely ‘Eq.Refl’ In the second argument of ‘($)’, namely ‘Flay Eq.Refl’ In the second argument of ‘($)’, namely ‘hsubst f $ Flay Eq.Refl’ | 29 | fromLeibniz f = unflay $ hsubst f $ Flay Eq.Refl | ^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 06:14:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 06:14:31 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi Message-ID: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: operator | Operating System: Unknown/Multiple precedence | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a large project, it can be difficult to keep track of the precedence of operators. It would be a nice quality-of-life improvement if there were a GHCi command to list the current operators in scope by precedence. It could list them in a table like this: {{{ :operators | prec | nonassoc | leftassoc | rightassoc | |------+----------+-----------+------------| | 9 | !! | | . | | 8 | | | ^ ^^ ** | | 7 | * / | | | | 6 | + - | | | | 5 | | | : ++ | | 4 | | == | | }}} Perhaps it could list all infix operators, as well as functions that have a fixity declaration? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 13:06:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 13:06:45 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.e4afd21a7c17bd8ea9c91d9181459bdd@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, 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: operator precedence => operator precedence, newcomer Comment: Indeed this does look quite handy. Moreover, it should be pretty easy to implement; perhaps you are interested in giving it a shot? I'm happy to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 13:26:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 13:26:45 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.c2c351a4550f95c5d0d65a8a351af475@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, 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): Should this be a [https://github.com/ghc-proposals/ghc-proposals/ ghc- proposal] first? I agree that this looks lovely and would likely be warmly welcomed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 13:42:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 13:42:45 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers Message-ID: <044.f762bf620383822c5337aa8807210278@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64. **Code that produces wrong results** {{{ map (/2) [9007199254740990..9007199254740991] }}} **Expected behaviour** same as with low values: {{{ map (/2) [5..6] }}} resulting in: {{{ [2.5,3.0] }}} **Actual behaviour** resulting in an infinite list: {{{ [4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..] }}} **Similar code that produces expected results** multiplication works: {{{ map (*2) [9007199254740990..9007199254740991] }}} slightly smaller number work: {{{ map (/2) [9007199254740989..9007199254740990] }}} using a comma to produce the same list works: {{{ map (/2) [9007199254740990,9007199254740991] }}} **Similar code that also produces unexpected results** more elements in the list: {{{ map (/2) [9007199254740990..9007199254740999] map (/2) [9007199254740990..9007199354740999] }}} substituting the number and doing calculations: {{{ map (/2) [9007199254740990..9007199254740990+1] let a = 9007199254740990 map (/2) [a..a+1] }}} using scan and fold: {{{ foldl1 (/) [9007199254740990..9007199254740991] scanl1 (/) [9007199254740990..9007199254740991] }}} **Notes** This somehow only happens with high numbers when using fractional operations and using .. to construct the list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 13:44:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 13:44:40 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.b46c04760252b619cb6106add4e168eb@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 13:58:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 13:58:56 -0000 Subject: [GHC] #15082: Split the TrieMap module into a generic and core specific part. Message-ID: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> #15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4618 | Wiki Page: -------------------------------------+------------------------------------- == Split the module into two parts. Motivation: I came across a situation where I would have liked to make LabelMap a instance of TrieMap. However this would create a transitive dependency on CoreSyn for essentially all Cmm related Modules which seemed excessive. Splitting TrieMap into a general and Core specific part changes this. It also leads to a nicer separation of concerns. I have implemented a first version of this in D4618. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 14:00:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 14:00:39 -0000 Subject: [GHC] #15082: Split the TrieMap module into a generic and core specific part. In-Reply-To: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> References: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> Message-ID: <062.57003da548df49eb2cd5ffee3085c22f@haskell.org> #15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4618 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 14:01:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 14:01:17 -0000 Subject: [GHC] #15082: Split the TrieMap module into a generic and core specific part. In-Reply-To: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> References: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> Message-ID: <062.c10ed900ea60a4dcba9f0367a50079f7@haskell.org> #15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4618 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 14:13:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 14:13:26 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.a6dace2e17eeefc48ececf2016a835c6@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Looking at one of the regressions, T9010, I set up a trap to catch only those coercions that are found to be equal by `eqType`, but don't match on `isReflCo`. And they're all the same: `(State# RealWorld -> (# State# RealWorld, () #), State# RealWorld -> (# State# RealWorld, () #))`. So this one looks like it would be relatively easy to detect. Unfortunately, the other one, T12707, paints a different picture; here, the matches look like these: {{{ (forall a. K1 R Bool a -> [String] -> [String], forall a. K1 R Bool a -> [String] -> [String]) }}} {{{ (forall a. M1 S ('MetaSel ('Just "foo3Field08") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (K1 R (Maybe Bool)) a -> [String] -> [String], forall a. M1 S ('MetaSel ('Just "foo3Field08") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) a -> [String] -> [String]) }}} {{{ (forall a. (:*:) (((S1 ('MetaSel ('Just "foo0Field00") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field01") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field02") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field03") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field04") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool)))) :*: ((S1 ('MetaSel ('Just "foo0Field05") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field06") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field07") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field08") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field09") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool))))) (((S1 ('MetaSel ('Just "foo0Field10") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field11") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field12") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field13") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field14") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool)))) :*: ((S1 ('MetaSel ('Just "foo0Field15") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field16") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field17") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field18") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field19") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool))))) a -> [String] -> [String], forall a. (:*:) (((S1 ('MetaSel ('Just "foo0Field00") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field01") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field02") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field03") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field04") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool)))) :*: ((S1 ('MetaSel ('Just "foo0Field05") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field06") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field07") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field08") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field09") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool))))) (((S1 ('MetaSel ('Just "foo0Field10") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field11") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field12") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field13") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field14") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool)))) :*: ((S1 ('MetaSel ('Just "foo0Field15") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 String) :*: S1 ('MetaSel ('Just "foo0Field16") 'NoSourceUnpackedness 'SourceStrict 'DecidedUnpack) (Rec0 Int)) :*: (S1 ('MetaSel ('Just "foo0Field17") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [Int]) :*: (S1 ('MetaSel ('Just "foo0Field18") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 (Maybe Bool)) :*: S1 ('MetaSel ('Just "foo0Field19") 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 Bool))))) a -> [String] -> [String]) }}} Further digging, however, reveals that these are all `Sym` coercions, so I think I can figure out a faster way to detect these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 14:37:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 14:37:40 -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.3b07fa1603f2a31cf19f4578b6c11796@haskell.org> #13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: sighingnow 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: (none) => sighingnow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 15:58:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 15:58:53 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.66eecd109469d065ce4630f34868bf68@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): This very problem was causing a whole bunch of tests to fail when running `./validate --slow`: {{{ /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/T12733/T12733.run T12733 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal01/t.run cabal01 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./driver/T3007/T3007.run T3007 [bad stderr] (normal) /run/user/1001/ghctest-qrii3s_s/test spaces/./patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) /run/user/1001/ghctest-tkhsza6q/test spaces/./cabal/T12733/T12733.run T12733 [bad stderr] /run/user/1001/ghctest-tkhsza6q/test spaces/./driver/T3007/T3007.run T3007 [bad stderr] (normal) }}} I have a patch that fixes those tests, it simply implements Ben's suggestion. It's now up on phab as [https://phabricator.haskell.org/D4628 D4628]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 15:59:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 15:59:59 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.cfc4151e5bc9d21b3f104667ed8b4b9b@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): D4628 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) * status: new => patch * differential: => D4628 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:08:53 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc In-Reply-To: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> References: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> Message-ID: <060.f2abcb0d021c04947bb13fd5ff31a4eb@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e7322107d3647e5d3097eeca878e036b1c98557b/ghc" e7322107/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7322107d3647e5d3097eeca878e036b1c98557b" ghc-prim: Refactor and document __sync_fetch_and_nand workaround ed6f9fb9d5a684d2159c29633159c3254cf04deb reduced the scope of this hack to only include Clangs which actually lack __sync_fetch_and_nand. However, this causes GHC to fail to build with -Werror on Clang due to the lack of the -Wsync-nand warning flag. As it turns out a flag controlling the warning is available under a different name, however. Test Plan: Validate with Clang, GCC Subscribers: thomie, carter GHC Trac Issues: #9678 Differential Revision: https://phabricator.haskell.org/D4613 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:08:53 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.d5fde670a331f395744e6cf34fa360f4@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T13623 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1126e6942624f4e6578e59b2a28b9848ad9fcea2/ghc" 1126e69/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1126e6942624f4e6578e59b2a28b9848ad9fcea2" testsuite: Fix overflow in T13623 on 32-bit machines We simply truncate the result to 32-bits to ensure that the test passed under both environments. Test Plan: Validate on 32-bit Subscribers: thomie, carter GHC Trac Issues: #13623 Differential Revision: https://phabricator.haskell.org/D4615 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:08:53 -0000 Subject: [GHC] #11953: Export Word32#, Word64# on all architectures In-Reply-To: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> References: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> Message-ID: <061.09c70699acf77bd6a85466a40ced4acc@haskell.org> #11953: Export Word32#, Word64# on all architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ec9638b222433b33943b3c4319d1d5cf91313b0c/ghc" ec9638b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec9638b222433b33943b3c4319d1d5cf91313b0c" testsuite: Fix T4442 on 32-bit architectures This relied on Int# being 64-bits. This is nothing a bit of CPP can't fix, but I think the right solution would be to make out treatment of word-size dependent types more consistent, as suggested by #11953. Test Plan: Validate on i386 Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4614 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:26:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:26:14 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.5cd1ba33d9a8a738f3f08723680e39ad@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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 bgamari): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:26:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:26:38 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.5399552943b461fd0c80d3349aa3f0fe@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 bgamari): Any update on this, andrewthad? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:34:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:34:19 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.e57f5aa7d7f76c9df540bcd796cd101f@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See my note on Phab. (Phab seems to only offer "Tell no one" these days, which is a huge pain. On each occasion I have to take a second step to put a note on the ticket to tell people to look at Phab. Seems sub-optimal.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 16:39:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 16:39:07 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.d4208cfaecb50f8af0391da7e8facd95@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, 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): A good question; I suppose it wouldn't hurt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 17:03:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 17:03:31 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.ba6e89f4a31cebcc65430eece71c276f@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > (Phab seems to only offer "Tell no one" these days, which is a huge pain. On each occasion I have to take a second step to put a note on the ticket to tell people to look at Phab. Seems sub-optimal.) Indeed this is a consequence of a recent upgrade. I am working with upstream to remedy the situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 19:57:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 19:57:40 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.8fe74eb0807bc133ffd23640d5bab9d6@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): I just spent some time making it a little more minimal. It's down to about 450 lines of code at this point, which is still pretty high. I've also consolidated the modules somewhat. I'll keep trying to get this smaller over the next few days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 19:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 19:58:36 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.3eca58737fbd8b60a2d6475745fabba5@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Do we have a specification for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 20:11:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 20:11:26 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.aff824fa6f0b7f300288d9898579ed50@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message is perplexing, because it suggests that we have failed to prove {{{ forall i. i -> * ~# forall k. k -> * }}} Why? It seems that their visibility-flag differs, as you see if you use `-fprint-explicit-foralls` (which Joe User will never think of): {{{ T15079.hs:19:34: error: * Kind mismatch: cannot unify (c0 :: forall i. i -> *) with: Coerce :: forall {k}. k -> * Their kinds differ. Expected type: a -> c0 * a Actual type: Starify a -> Coerce a }}} `tcEqType` took no account of the visibility flag before. Is this anything to do with making the flattener homogeneous?? I see that `TcType.tcEqType` has grown two new bells * It returns a `Maybe Bool` with this rubric {{{ -- Nothing : the types are equal -- Just True : the types differ, and the point of difference is visible -- Just False : the types differ, and the point of difference is invisible }}} But why? We didn't do that before. * The treatment of `ForAllTy` has changed: {{{ go vis env (ForAllTy (TvBndr tv1 vis1) ty1) (ForAllTy (TvBndr tv2 vis2) ty2) = go (isVisibleArgFlag vis1) env (tyVarKind tv1) (tyVarKind tv2) go vis (rnBndr2 env tv1 tv2) ty1 ty2 check vis (vis1 == vis2) }}} Notice that `check vis (vis1 == vis2)`. That means we say not-equal if the visibility flags differ. But why? These flags are constants, so if they differ now they'll always differ and cannot be unified. I have no idea what is going on here. Richard can you shed some light? I'll grant that it's a bit suspicious to say that two forall type are the same if their visibility flags differ. But in this case, yes, `Coerce`'s kind has an Inferred forall, whereas `c`'s kind is Specified. Does that mean they are incompatible? I can't foresee all the consequences of such a decision. At very least, here's a pretty-printer suggestion: if we do print a `forall` at all (as we do in this error message) maybe we should always display its visibility status? Otherwise error messages like this are desperately confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 20:22:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 20:22:16 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.f9259320c880151a219852db82634679@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * differential: D4628 => Phab:D4628 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 21:57:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 21:57:30 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.74e9d8226b226a8b411122a1981ebf1d@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Looking at one of the regressions, T9010, I set up a trap to catch only those coercions that are found to be equal by eqType, but don't match on isReflCo. And they're all the same: ... Eh? The code you give doesn't look like a coercion. It looks like a type, or a pair of types. I must be misunderstanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 23:05:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 23:05:15 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.382035653f504aef06431f65c708692b@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Your patch looks fine. Easiest to leave `SigTv` alone; and just change what sort of tyvar is used in a pattern type signature; which is what you have done. It's a simple change. Just a question of deciding what we want. I'm ok with binding a type variable to an arbitrary type. GHC proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 23:25:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 23:25:00 -0000 Subject: [GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples In-Reply-To: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> References: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> Message-ID: <060.5373e0bc63ce7f98a6422634fd6ad151@haskell.org> #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > `unsafeCoerce :: (A -> B) -> A -> (# B #)` I think you are right that this is ok. But the reverse is not {{{ unsafeCoerce :: (A -> {# B #)) -> A -> B }}} because the argument function may return an unevaluated `B`, while the returned function is supposed to guaranteed to return an evaluated `B`. Tricky. > The first version in particular would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations. Would you care to explain your use-case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 24 23:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Apr 2018 23:32:18 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.b544408fa78ab8c0084d88e478d3c616@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost with this example. I think that, because of `OverloadedLists` it desugars as {{{ foo (toList -> []) = Empty foo (toList -> (x : xs)) = x :! foo xs }}} But then we actually need the `[]` (list) instance of `toList` which is the identity function? Then what? How does the bogus error message arise? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 00:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 00:29:24 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.815df6a225fd5555f923db0647cf0b04@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): During the exhaustiveness checking, we already know the type of `[]`, we use `splitListTyConApp_maybe` to check whether it's type is `[a]` (list) or not and extract its element type. {{{#!hs splitListTyConApp_maybe :: Type -> Maybe Type splitListTyConApp_maybe ty = case splitTyConApp_maybe ty of Just (tc,[e]) | tc == listTyCon -> Just e _other -> Nothing }}} Indeed we don't need to know the `toList` of `[]` instance is identity function, we know the type of the pattern is `[]` then the `toList` is omitted and it is enough to know `[]` is the nil pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 01:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 01:26:09 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.026488164fd396f666a1217e24ce45ad@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Easiest to leave `SigTv` alone; and just change what sort of tyvar is used in a pattern type signature; which is what you have done. You don't the name to be changed? Good with me. > GHC proposal? There are so many proposals already … but I guess that’s a good thing :-) Will whip something up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 01:37:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 01:37:25 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.f8107e0f57a32ace82a5954cc3aebfea@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 sighingnow): Look at the enumerate method for fractional types: {{{#!hs numericEnumFrom :: (Fractional a) => a -> [a] numericEnumFrom n = n `seq` (n : numericEnumFrom (n + 1)) numericEnumFromTo :: (Ord a, Fractional a) => a -> a -> [a] numericEnumFromTo n m = takeWhile (<= m + 1/2) (numericEnumFrom n) }}} A possible improvement should be recording the accumulate increment and add it to the base number, rather than `+1` every time. For `Double` (64-bit floating point), the number `9007199254740991 + 1/2` has binary representation: {{{ 0x4340000000000000 }}} However, the number * `9007199254740990` is: `0x433ffffffffffffe` * `9007199254740990 + 1` is `0x433fffffffffffff` * `(9007199254740990 + 1) + 1` is `0x4340000000000000` * `((9007199254740990 + 1) + 1) + 1` is `0x4340000000000000` Note that `(9007199254740990 + 1) + 1` has the same binary representation with `((9007199254740990 + 1) + 1) + 1`, so the condition `(<= m + 1/2)` will always hold. Then we get the infinite list. If we change the upper bound, for example, {{{ map (/2) [9007199254740989..9007199254740990] }}} It works fine and prints `[4.5035996273704945e15,4.503599627370495e15]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 01:40:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 01:40:32 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.061c751bdcb8a398530816e9abb4de5c@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): My additional changes have been pushed to the github repo. Also, here's my two cents about what I think is going on. The thing that causes the problem appears to be: {{{ snmptrapdNaive :: Naive.Trie (Parser Word) snmptrapdNaive = Naive.fromStringList [ ("STRING: ", P.any >>= \_ -> return 5) ] }}} If I use my parser language to simply build up a parser, and then I run the parser, everything works fine. However, sticking it inside of some other data structure seems like it causes problems (I'm not sure if it matters that the value is a CAF). Also, my parser type is a newtype wrapper around a function that uses unboxed sums. I'm also not sure if that matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 01:46:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 01:46:58 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.a0c324e470944be2285221e9ae3f9f5f@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Proposed at https://github.com/ghc-proposals/ghc-proposals/pull/128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 05:14:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 05:14:16 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.31cd5ada76882ff96799cd9c74d0c7d7@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): > See my note on Phab. Thanks for being so responsive. I just left 2 comments on the differential as well, trying to find a solution that makes everyone happy. It should not be too hard given the small number of users of that `unionLists` function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 06:27:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 06:27:00 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.a9394ca2e12812cc94f73dedb4b5f863@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:5 simonpj]: > Eh? The code you give doesn't look like a coercion. It looks like a type, or a pair of types. I must be misunderstanding. Sorry about that, didn't realize that this was misleading without the relevant context. So we have this code here: {{{ pushCoTyArg co ty | isReflCo co = Just (ty, Nothing) -- The following is inefficient - don't do `eqType` here, the coercion -- optimizer will take care of it. See Trac #14737. | tyL `eqType` tyR = pprTrace "eqType fired: " (ppr (tyL, tyR)) $ -- <- this is where we're doing the trace logging Just (ty, Nothing) | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) Just (ty `mkCastTy` mkSymCo co1, Just co2) | otherwise = Nothing where Pair tyL tyR = coercionKind co -- co :: tyL ~ tyR -- tyL = forall (a1 :: k1). ty1 -- tyR = forall (a2 :: k2). ty2 }}} So the two types we see in this log are `tyL` and `tyR`, calculated using `coercionKind co`. And our goal is to find a drop-in replacement for `isReflCo` that detects most of the coercions that hit the `eqType` guard right now, but is significantly cheaper than `eqType` (and `coercionKind` / `coercionKindRole`). It may become less confusing if we dump the actual coercion too: {{{ pushCoTyArg co ty | isReflCo co = Just (ty, Nothing) -- The following is inefficient - don't do `eqType` here, the coercion -- optimizer will take care of it. See Trac #14737. | tyL `eqType` tyR = pprTrace "eqType fired: " (ppr (co, tyL, tyR)) $ Just (ty, Nothing) }}} This gives us output like the following: {{{ eqType fired: (Sym (N:GQuu[0] _N) ; N:GQuu[0] _N, forall a. K1 R Bool a -> [String] -> [String], forall a. K1 R Bool a -> [String] -> [String]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 06:52:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 06:52:34 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.588c73f341b7e927cd4b29718f679788@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 osa1): Thanks for simplifying the code. I made an attempt at removing unboxed sums (and had to remove some unboxed tuples on the way) [https://github.com/andrewthad/corrupted-memory- example/pull/1 here], and that made the bug disappear. So this may be related with unboxed tuples/sums. > If I use my parser language to simply build up a parser, and then I run the parser Can you elaborate on this? What do you mean by building your parser language? Can you share the code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 06:58:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 06:58:31 -0000 Subject: [GHC] #15083: cannot install GHC on CentOS Message-ID: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> #15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- This is the information of my system: {{{ > cat /etc/*release CentOS Linux release 7.4.1708 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" }}} I want to build a Stack project on this system, but I receive an "impossible" error even when I try to build a trivial project. {{{ >wget https://www.stackage.org/stack/linux-x86_64-static >tar -xzf linux-x86_64-static > cp stack-1.6.5-linux-x86_64-static/stack .local/bin/ > stack new stacktest Downloading template "new-template" to create project "stacktest" in stacktest/ ... The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username You can provide them in /home/users/ksb/.stack/config.yaml, like this: templates: params: author-email: value author-name: value category: value copyright: value github-username: value Or you can pass each one as parameters like this: stack new stacktest new-template -p "author-email:value" -p "author- name:value" -p "category:value" -p "copyright:value" -p "github- username:value" Looking for .cabal or package.yaml files to use to init the project. Using cabal packages: - stacktest/ Selecting the best among 13 snapshots... * Matches lts-11.6 Selected resolver: lts-11.6 Initialising configuration using resolver: lts-11.6 Total number of user packages considered: 1 Writing configuration to file: stacktest/stack.yaml All done. > stack build [1 of 2] Compiling Main ( /home/users/ksb/.stack/setup-exe-src /setup-mPHDZzAJ.hs, /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): toStgWord: Unknown platformWordSize: 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building simple Setup.hs using: /home/users/ksb/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-2.0.1.0 /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.hs /home/users/ksb/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -o /home/users/ksb/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 Process exited with code: ExitFailure 1 }}} Can you help me identify why this build failed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 07:12:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 07:12:02 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.4466a6f8d90a31f5fd8495fd7671c9be@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 osa1): Great analysis @sighingnow. You don't actually need the map, here's a simpler reproducerL {{{ $ ghci GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> [9007199254740990..9007199254740991] :: [Double] }}} This prints an infinite list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 07:36:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 07:36:11 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.407c5e613b3265217f1307995b547020@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Indeed we don't need to know the toList of [] instance is identity function, Good point. So this ticket is * not about overloaded strings * not about type functions It's only about view patterns. Could you re-formulate the example to eliminate the unnecessary clutter, and focus just on view patterns? And then (sorry to be slow) take us more slowly through what the problem is? It'll be something to do with the way that the pattern match checker deals with view patterns, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 07:41:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 07:41:39 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.1e3fa5488d6c88b7337afa2208fadf04@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > You don't the name to be changed? Well, not yet. Comments, maybe! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 07:54:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 07:54:10 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.2ee6eb97f5a8c8cb49937c5a32f4f884@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 simonpj): Yes, dead right. Does not look hard to fix, if someone could look at the library instances for `Enum Double` and `Float`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:10:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:10:04 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.bbf49a900ea83e44b81a188db2c7fe0e@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, much easier to understand. Now my next question is this: who built that coercion? It is actually reflexive, and it's trivial to see that; but it is not `ReflCo`. Usually we build coercions with smart constructors that rapidly smash to `ReflCo`. Can you describe how to reproduce this exact example? I can't get it to trip on `T9020` and `T12707` seems much larger. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:19:52 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.df35343085cba30e901c2d972408651b@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): My previous comment addresses on `toList`, leading to some confusion. The ticket **IS** about the type functions. Look the `ListPat` case in `translatePat` (after the patch Phab:D4624): {{{#!hs -- overloaded list ListPat x lpats elem_ty (Just (pat_ty, _to_list)) | Just e_ty <- splitListTyConApp_maybe pat_ty , (_, norm_e_ty) <- normaliseType fam_insts Nominal e_ty -- e_ty can be a type family instance, like -- `It (List a)`, but we prefer `a`, see Trac #14547 , (_, norm_elem_ty) <- normaliseType fam_insts Nominal elem_ty -- elem_ty is frequently something like -- `Item [Int]`, but we prefer `Int` , norm_elem_ty `eqType` norm_e_ty -> -- We have to ensure that the element types are exactly the same. -- Otherwise, one may give an instance IsList [Int] (more specific than -- the default IsList [a]) with a different implementation for `toList' translatePat fam_insts (ListPat x lpats e_ty Nothing) -- See Note [Guards and Approximation] | otherwise -> mkCanFailPmPat pat_ty }}} For pattern `[]` in `foo [] = Empty`, we have ||pat_ty || `[It (List a_a2mv)]` || ||e_ty || `It (List a_a2mv)` || ||norm_e_ty || `a_a2mv` || ||elem_ty || `GHC.Exts.Item [a_a2mv]` || ||norm_elem_ty || `a_a2mv` || Before Phab:4624, we compared `norm_elem_ty` with `e_ty`, rather than `norm_e_ty`, then we failed to know the `[]` is list's nil pattern. We need also normalize the `e_ty` and this ticket is only about the type function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:33:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:33:23 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.e30857af6b36b42b5cbef60a23ff6cc6@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: 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): > If the CLC elects not to/does not decide on a name, I feel like it should be @simonpj's decision, as the Libraries Mailing List could not decide. I wrote to the CLC today: https://mail.haskell.org/pipermail/libraries/2018-April/028736.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:35:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:35:39 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type Message-ID: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 1aa1d405d8212a99ac24dcfd48024a17c3ffd296 the types of a lot of functions in `HsUtils` was changed and now they are too restrictive. For example, `nlHsfunTy` has the following type. {{{ nlHsFunTy :: LHsType (GhcPass p) -> Rig -> LHsType (GhcPass p) -> LHsType (GhcPass p) }}} It should instead be given the more general type which will allow it to work as before in many situations. {{{ nlHsFunTy :: (XFunTy p ~ PlaceHolder) => LHsType p -> Rig -> LHsType p -> LHsType p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:39:22 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.94a07f235009c3200b914de916a000ca@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Alan/Shayan should say, but I think using `GhcPass p` rather than `p` might do the job more simply -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 08:54:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 08:54:35 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.b230e8f9b3f9277434101c89614a7e92@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It breaks downstream consumers such as Haddock which ends up with `LHsType DocStringI`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 09:00:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 09:00:35 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.7b52acacef98f3109f2e43c5ac194009@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, hmm, I think I see. Given something like {{{ f (toList -> []) = e1 f (toList -> (a:as)) = e2 }}} we'd like to declare this function exhaustive. (Clearly it is!) The `ListPat` case of `Check.translatePat` deals with a very special sub- case. * Using `OverloadedLists`, we generate a special kind of view pattern, encoded in the `ListPat` constructor of `Pat`: {{{ | ListPat (XListPat p) [LPat p] (PostTc p Type) -- The type of the elements (Maybe (PostTc p Type, SyntaxExpr p)) -- For rebindable syntax -- For OverloadedLists a Just (ty,fn) gives -- overall type of the pattern, and the toList -- function to convert the scrutinee to a list value }}} * You are checking that the function actually has type `[t1] -> [t2]`, where `normalise t1 = normalise t2`. * In that case, you discard the `toList` view thing altogether, and pretend (for the purposes of pattern-match checking) that you wrote {{{ f [] = e1 f (a:as) = e2 }}} This would not be valid if you'd had {{{ f (toList -> []) = e1 f (weirdToList -> (a:as)) = e2 }}} with two different `toList` functions. But in this special case the view function was injected by the type-driven overloading machinery, so we can be confident (I think) that both functions are the same. So ''at least'' all this should be explained in a Note. But it also seems like a special case that is easily defeated. For example, what about this: {{{ f :: T -> blah f (toList -> []) = ... f (toList -> (x:xs) = ... }}} This too is exhaustive, but it won't be recorded as such, even if you use `OverloadedLists`. And of course if you use explicit view patterns, things are even worse. At least the Note should point out these deficiencies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 09:12:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 09:12:29 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.15abced59e598da06b2f465481990003@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 dredozubov): @jship thanks for the info, I tried it with a few work projects and it still fails for some of them, which is very frustrating. It seems like I have to get a tad more familiar with OS X linking tools to get to the bottom of it. I tried to bruteforce my way by adding `-optl-fuse-ld=ld- wrapper-macos.sh` to all the cabal targets in the repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 10:26:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 10:26:35 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.1e06794026e032cd617c193152d1b200@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, sure. Just check out GHC HEAD, and apply this patch: {{{ diff --git a/compiler/coreSyn/CoreOpt.hs b/compiler/coreSyn/CoreOpt.hs index f1ff68d133..6ddab2c94e 100644 --- a/compiler/coreSyn/CoreOpt.hs +++ b/compiler/coreSyn/CoreOpt.hs @@ -958,10 +958,14 @@ pushCoTyArg :: CoercionR -> Type -> Maybe (Type, Maybe CoercionR) -- If the returned coercion is Nothing, then it would have been reflexive; -- it's faster not to compute it, though. pushCoTyArg co ty + | isReflCo co + = Just (ty, Nothing) + -- The following is inefficient - don't do `eqType` here, the coercion -- optimizer will take care of it. See Trac #14737. - -- -- | tyL `eqType` tyR - -- -- = Just (ty, Nothing) + | tyL `eqType` tyR + = pprTrace "eqType fired: " (ppr (co, tyL, tyR)) $ + Just (ty, Nothing) | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) @@ -993,10 +997,15 @@ pushCoValArg :: CoercionR -> Maybe (Coercion, Maybe Coercion) -- If the second returned Coercion is actually Nothing, then no cast is necessary; -- the returned coercion would have been reflexive. pushCoValArg co + -- The "easy" case; this doesn't interest us. + | isReflCo co + = Just (mkRepReflCo arg, Nothing) + -- The following is inefficient - don't do `eqType` here, the coercion -- optimizer will take care of it. See Trac #14737. - -- -- | tyL `eqType` tyR - -- -- = Just (mkRepReflCo arg, Nothing) + | tyL `eqType` tyR + = pprTrace "eqType fired: " (ppr (co, tyL, tyR)) $ + Just (mkRepReflCo arg, Nothing) | isFunTy tyL , (co1, co2) <- decomposeFunCo Representational co }}} Build with the `validate` flavor, and then: {{{ ./inplace/bin/ghc-stage2 -O2 testsuite/tests/perf/compiler/T9020.hs -fforce-recomp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 11:44:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 11:44:09 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.7b5d808d4bf41252292083849876c821@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 andrewthad): The full original code is the `packed` repository (along with its test suite): https://github.com/andrewthad/packed. The minimal example repo I put up is just `packed` but with everything that wasn't needed to make the error happen stripped out. Here is an example of a parser that I build in the original code that doesn't cause errors: https://github.com/andrewthad/packed/blob/master/test/Parser.hs#L112-L122. None of the parsers from the original test suite ever cause crashes excepted for the trie-based one where a `Parser` is nested inside of a `Trie`, which causes a crash whenever the GC is run. Let me know if there's a way that I can clarify this further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 12:53:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 12:53:07 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.21c2e5826988ee0f1d47992ff5495ec3@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, got it. The culprit is this: {{{ addCoerce co1 (CastIt co2 cont) = addCoerce (mkTransCo co1 co2) cont }}} It's really very common for `co1` and `co2` to cancel each other out, but `mkTransCo` doesn't spot that. Next thing to try: {{{ addCoerce co cont | isReflCo co = return cont addCoerce co1 (CastIt co2 cont) | isReflexiveCo co' = return cont | otherwise = {-#SCC "addCoerce-simple-recursion" #-} addCoerce co' cont where co' = mkTransCo co1 co2 }}} And get rid of the `isReflexiveCo` at the end altogether. The initial `isReflCo` is optional -- just to catch the case where the `simplCorecion` returns Refl. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 13:42:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 13:42:12 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.e11419ea433a22ecb7e5ae5f174f814e@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:9 simonpj]: > OK, got it. The culprit is this: > {{{ > addCoerce co1 (CastIt co2 cont) > = addCoerce (mkTransCo co1 co2) cont > }}} > It's really very common for `co1` and `co2` to cancel each other out, but `mkTransCo` doesn't spot that. Next thing to try: > > {{{ > addCoerce co cont > | isReflCo co = return cont > > addCoerce co1 (CastIt co2 cont) > | isReflexiveCo co' = return cont > | otherwise = {-#SCC "addCoerce-simple-recursion" #-} > addCoerce co' cont > where > co' = mkTransCo co1 co2 > }}} > And get rid of the `isReflexiveCo` at the end altogether. > > The initial `isReflCo` is optional -- just to catch the case where the `simplCorecion` returns Refl. Yes, this does seem to work. Running some tests to verify. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 14:53:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 14:53:02 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.7a11566f599192b0250788591cb8a1ce@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Comments, maybe! Sure, I will have to go through all of the related notes (which are already partly out-of-date even before my patch). I’ll do that after the proposal process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 14:54:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 14:54:54 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.304b7558bcf5471ade3989909eef5dae@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 svenpanne): Hmmm, even with the improved instances, aren't we just shifting the problem by one bit? The underlying problem stays: You can write more precise Integers than Double can represent, and enumerating floating point numbers is inherently fragile. People tend to assume initially that {{{#!haskell map (/2) [9007199254740990..9007199254740991] }}} behaves like {{{#!haskell map ((/2) . fromIntegral) [9007199254740990..9007199254740991] }}} which is something different because of defaulting/typing rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 15:02:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 15:02:24 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix Message-ID: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Put `x = ()` in test.hs. 2. Start ghci. 3. Turn on collection with :set +c. 4. Load the file with :l test.hs. 5. Observe the following output from :all-types {{{ test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} 6. While ghci is still open, modify the file to say `x = True`. 7. In the same ghci session as before, reload with :r, or load the file again with :l test.hs, chef's choice. 8. Run :all-types again. After step 8, ghci prints the exact same thing as before, indicating that both sides of the equation have type `()`. It should instead update the source spans and types to match the file, reporting `Bool` instead of `()` and `(1,5)-(1,9)` for the second span. Manually exiting and restarting ghci appears to be the only way to freshen the collected type information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 16:24:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 16:24:25 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.1c7b973cf82eb9f3f1802c8515495fe9@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I rebased `wip/llf` onto a recent HEAD commit. You can find my progress here: https://github.com/sgraf812/ghc/tree/llf. Currently, it doesn't pass the testsuite (even in default mode, which doesn't do any new lambda lifting), probably because I introduced some errors during the merge. I think we should continue the discussion in #9476. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 16:29:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 16:29:05 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.69ff977a3c3f558f1111d50ad43f3376@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: I rebased Nicholas Frisby's work here: https://github.com/sgraf812/ghc/tree/llf. It doesn't currently pass the testsuite (even in default mode, not doing any llf), probably because I introduced some errors while merging some decision code and taking care of join point (then still running by let-no- escape) information. In particular, the devel2 version triggers an ASSERT in `add_id`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 17:33:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 17:33:26 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.e8883d84d121dee78a851095b34d1a80@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): OK, great. Do keep us posted. I think there are real wins to be had here. Nicholas's detailed wiki page identifies many of the issues very clearly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 17:35:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 17:35:49 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.6e432d67d33923631347a1da1fe576e0@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK the CLC chair Edward Kmett decided `Solo#`: https://mail.haskell.org/pipermail/libraries/2018-April/028740.html Would anyone like to make a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 17:38:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 17:38:42 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.3316c1033d75740fd0a5334606491a2c@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): chessai has a patch here: https://github.com/ghc/ghc/pull/96 I'm going to request that he update it on the github issue tracker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 17:43:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 17:43:30 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.44e39eb4aeeb8e1c0c7c06fbfc7c6e55@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: jme Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2031, Wiki Page: | Phab:D4627 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"acb73617abb23a16c2195459d8cefbf3febe26f3/ghc" acb73617/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acb73617abb23a16c2195459d8cefbf3febe26f3" Stable.c: minor refactoring, add/update some comments Test Plan: Passes validate Reviewers: simonmar, bgamari, erikd Subscribers: thomie, carter GHC Trac Issues: #10296 Differential Revision: https://phabricator.haskell.org/D4627 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 18:38:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 18:38:27 -0000 Subject: [GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples In-Reply-To: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> References: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> Message-ID: <060.96f02fbb5e4f5765df50de85a5098cfb@haskell.org> #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Consider {{{#!hs adjust, adjust' :: (a -> a) -> Seq a -> Seq a }}} The lazy version can leak memory, but it's been around for years so we need to support it. The study version is efficient. Both versions can be defined using a more general operation: {{{#!hs adjust# :: (a -> (# a #)) -> Int -> Seq a -> Seq a adjust f = adjust# (\x -> (# f x #)) adjust' f = adjust# (\x -> let !x' = f x in (# x' #)) }}} `adjust#` allows the given function to perform as much work as it wants, then suspend as much further work as it wants. The definitions of `adjust` and `adjust'` above add a closure allocation and a bit of indirection over the equivalent direct definitions, unless we inline and duplicate code. For `adjust`, which already leaks memory, that's tolerable. For `adjust'`, it's not. What can we do? Define {{{#!hs adjust' f = adjust# (unsafeCoerce f) }}} That should just work. Since the result of applying `f` is interested by `adjust#` as an unboxed unary tuple, it gets forced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 19:22:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 19:22:56 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.91fc3154309077ecd97c589a2c3e5114@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harry): I got the same error. It happens for me when I run out of memory. My Computer freezes for some minutes as soon as the limit is reached. Interestingly my courser turns invisible after resuming control. Also one time X died. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 21:41:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 21:41:46 -0000 Subject: [GHC] #15086: hT profiling option Message-ID: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html #rts-options-for-heap-profiling The docs] indicate that you can pass `-hT` as an RTS option for memory profiling "by heap closure type". However, GHC 8.4.2 claims `invalid heap profile options: -hT`, and this option is not listed among the usage options printed with the error. The user guide for GHC 8.2.2 also mentions -hT, and I believe that GHC-8.2.2 also did not permit the option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 22:04:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 22:04:04 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.47241191a1e03bce2856a952f5e8acff@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by crockeea): I cannot reproduce in 8.4.2, so this looks fixed to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 22:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 22:08:34 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling Message-ID: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When running my large program with `+RTS -hb`, I get the following error: {{{ internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.4.2 for x86_64_unknown_linux) }}} Unfortunately, I'm unable to find a minimal example. (Side note: I doubt this is relevant, but this is a multi-threaded program. I first tried to profile with `+RTS -N4 -hb`, but got `-hb cannot be used with multiple capabilities`. I assumed this means it doesn't like `-N4` with `-hb`, so I removed `-N4` and got the above error.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 22:30:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 22:30:14 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.d8cb055bfe9efadeb62744fe75398835@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: backpack, | TypeFamilies, hs-boot 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 ekmett): * cc: ekmett (added) Comment: Just had this bite me as well. I have a backpack signature in which I want to state requirements about several type instances being defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 22:55:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 22:55:02 -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.c115a4499c5d9133697037744761d644@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 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 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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 23:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 23:32:18 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.9c84dad7276416316cff7d92a904b623@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15063 Comment: This is possibly related to #15063, which fails with the same error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 23:32:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 23:32:40 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.7ff32b331980f7413e31cf670dc2a0cf@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15087 Comment: This is possibly related to #15087, which fails with the same error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 23:37:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 23:37:08 -0000 Subject: [GHC] #15028: Deprecate and Remove Data.Semigroup.Option and Data.Monoid.First/Last (was: Deprecate and Remove Data.Semigroup.Option/First/Last) In-Reply-To: <049.03897d3322661841e0dfff5e5126841a@haskell.org> References: <049.03897d3322661841e0dfff5e5126841a@haskell.org> Message-ID: <064.9d643a3420e4cb6d8f4cc8149b1eb0f9@haskell.org> #15028: Deprecate and Remove Data.Semigroup.Option and Data.Monoid.First/Last -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 23:38:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 23:38:47 -0000 Subject: [GHC] #15028: Deprecate and Remove Data.Semigroup.Option and Data.Monoid.First/Last In-Reply-To: <049.03897d3322661841e0dfff5e5126841a@haskell.org> References: <049.03897d3322661841e0dfff5e5126841a@haskell.org> Message-ID: <064.18d523651067b7108879a43146ea66b3@haskell.org> #15028: Deprecate and Remove Data.Semigroup.Option and Data.Monoid.First/Last -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I have opened a PR adding warnings at https://github.com/ghc/ghc/pull/128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 25 23:48:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Apr 2018 23:48:23 -0000 Subject: [GHC] #15027: Remove WrappedMonad from Control.Applicative In-Reply-To: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> References: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> Message-ID: <064.f81783bf212886aa190256151634a6b2@haskell.org> #15027: Remove WrappedMonad from Control.Applicative -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base 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 andrewthad): * cc: ekmett, ryanglscott (added) * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 03:08:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 03:08:10 -0000 Subject: [GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() In-Reply-To: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> References: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> Message-ID: <060.10bb947ae264db043bb505d0deaae83e@haskell.org> #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Azel Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * owner: (none) => Azel Comment: I'm willing to have a go at this issue, is anyone already working on it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 08:22:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 08:22:42 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.cc04706ba6c26ed06079b816ea4d80d9@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow. With this change I see {{{ Unexpected stat failures: /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) (-7.9%) /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T5321FD.run T5321FD [stat too good] (normal) (-12.5%) /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T12425.run T12425 [stat too good] (optasm) (-9.5%) /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T9020.run T9020 [stat too good] (optasm) (-32.5%) /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T12707.run T12707 [stat too good] (normal) (-8.7%) /tmp/ghctest-c0sci53m/test spaces/./perf/compiler/T12227.run T12227 [stat not good enough] (normal) (+660%) }}} Clearly something is going pear shaped in `T12227` but the other numbers look fantastic for such a small change! Do you see this too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 09:11:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 09:11:57 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.4c7026bda353374daf1ceb9101c03e97@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Left another comment on the diff (not sure anyone gets emails from Phab when the diff is still a so-called "draft"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 09:13:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 09:13:03 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.6045ba84c9288631d68680ef4ec5a224@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Comment (by AndreasK): I did some work on this for the Cmm/STG stages. But so far the results still don't justify the complexity. Although it's pretty clear which things should be tried before further judgment can be made. I did implement a rudimentary version which detected recursion as likely and bottoming branches as unlikely. Overall performance was underwhelming. While most nofib programs got slightly faster (0-1%) very few got a lot (order of ~5%) slower. What I did not do yet is propagte the likelyhood info into the asm passes which is probably required. Without this we get some awkward interactions. For example we might have code of the sort: `if checkError() then {goto panic} else {goto foo};` Assuming another block also jumps to `foo` there are two ways to compile this block: {{{ check: cmp R1, 0 jnz panic jmp foo check2: cmp R1, 0 jz foo jmp panic }}} Performance of jumps to panic is essentially meaningless so we want variant two which saves an instruction in each loop. Blocklayout however turns this into a pessimization. We often get something like this: {{{ check: cmp R1, 0 jnz panic jmp foo bar: # few ins here #jmp foo foo: ins do things panic: some more instructions }}} This seems reasonable. If we are lucky bar is small enough that when we jump to foo we won't even miss the cache. But if we optimize the check block we suddenly get: {{{ check2: cmp R1, 0 jz foo # jmp panic #block layout assumes we will take this path panic: some more instructions bar: # few ins here #jmp foo foo: ins do things }}} Clearly we don't want this because it pulls check2 and foo far apart. But block layout assumes the last jump is the likely one so tries to place `panic` right after `check2`. If this is a loop there is a good chance that this causes a cache miss on each jump to foo. I did play around with the block layout code but without actually having likelyhood info I couldn't make it work better than what we have know. I do want to give lowering likelyhood info into the asm stage a try sooner or (probably) later since I would expect that to lead to much better code.. However for now I ran out of steam before I came up with a good way to tackle this. Things that need to be still done. - Find a good layout algorithm which can make use of partial information. There are descriptions for algorithms which work with full information about block entry counts. But Implementing one which works well on partial information is something I couldn't find anything on yet. Rolling my own is not out of the question but seems like something for a few weeks and not a few days. * Chose a design for lowering likelyhood information to the asm level. How isn't yet clear. Annotate the instructions? Add information about blocks in a sidechannel? It's also not static since things like the register allocator also generate new blocks on the fly. Shortcutting might remove blocks and so on. * Besides block layout if we lower that information it should also be used by the register allocators. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 09:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 09:36:27 -0000 Subject: [GHC] #15088: Test T3234 is fragile Message-ID: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- The test for T3234 is quite fragile as it compares the whole output of `-ddump-simpl-stats`. #3234 should be consulted and then the test modified so that only the relevant part is extracted and compared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 09:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 09:40:38 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.37c469441ec713780df85d391eb01cb2@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Comment (by simonpj): Is there a `wip` branch with your work, in case you or someone else wants to pick it up later? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 10:18:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 10:18:49 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.5520c1fe2a6da32f36c086bebae1843c@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: niteria (added) Comment: OK, so the culprit is the `unionLists` for the `imp_finsts` field of `ImportAvails`. Obvious ideas: 1. Represent `imp_finsts` as a `ModuleSet` 2. Represent `imp_finsts` as a `Bag Module` (ie with duplicates) There's a helpful `Note [Combine ImportAvails]` in `RnNames` which explains why a set is a bit awkward. My instinct is to try a `Bag` (so that `plusAvails` can use `unionBags` which is always fast), and move the removing-duplicates work to the consumer. I think there are two consumers of `imp_finsts`: * `tcExtendLocalFamInstEnv` loads up dependent modules. So we'd need eliminate duplicates, but determinacy is not an issue * `DsUsage.mkDependencies` which already does a sort, so removing dups at the same time should surely not be hard. Bartosz is the expert here. cc'd. * ` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 11:21:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 11:21:50 -0000 Subject: [GHC] #15027: Remove WrappedMonad from Control.Applicative In-Reply-To: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> References: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> Message-ID: <064.9bceedb11a393512c821e2856c8b7975@haskell.org> #15027: Remove WrappedMonad from Control.Applicative -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This is a duplicate. Closing in favor of #14200. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 11:22:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 11:22:07 -0000 Subject: [GHC] #15027: Remove WrappedMonad from Control.Applicative In-Reply-To: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> References: <049.f343c253b97e11e1b0452d3d4ff3ee0f@haskell.org> Message-ID: <064.cafd3cee10c582aaaf0ea1150ea16a79@haskell.org> #15027: Remove WrappedMonad from Control.Applicative -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: base 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 andrewthad): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 11:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 11:28:06 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.9d2128abf72df74d91f97610c07c4978@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:15 simonpj]: > Is there a `wip` branch with your work, in case you or someone else wants to pick it up later? Most of it is at wip/D4327 already. I plan to rebase my latest changes to master, make sure it compiles, is somewhat sane and then ask for someone to update that branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 11:43:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 11:43:27 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.ced8270e779cd945e20001b97bbee610@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Actually, no, I only see "stat too good" in T5321FD, T9020, T12707 and T12425. I just submitted differential Phab:D4635, so I guess we should see what harbormaster has to say on the matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 11:43:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 11:43:39 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad In-Reply-To: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> References: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> Message-ID: <066.16cf72143772e8831689c0540cd12f85@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13876 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I accidentally opened a duplicate of this ticket with #15027. I'm +1 on deprecating and removing this type. Related resources: Mailing list discussion: https://mail.haskell.org/pipermail/libraries/2018-April/028746.html GitHub PR: https://github.com/ghc/ghc/pull/129 It appears that this type still enjoys a small amount of use for backwards-compatibility purposes. This makes me wonder if `base-compat` might be a better home for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 12:13:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 12:13:37 -0000 Subject: [GHC] #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches Message-ID: <049.d7a6f5ef2f062ac53f62143ee65e850a@haskell.org> #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If you compile stage2 libraries with -g by using `GhcLibHcOpts` then many tests fail with stderr mismatch errors. It would perhaps be more robust to pass `-dsuppress-ticks` by default to tests so that it is possible to compile with debugging information and still run tests successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 12:54:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 12:54:25 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad In-Reply-To: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> References: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> Message-ID: <066.962a24227f9882d1ef0c0c61bd2e607e@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13876 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I do like the idea of moving `WrappedMonad` to `base-compat` (also note that I semi-broke the definition of `WrappedMonad` 3 years ago... so it'd be good if `base-compat` could retroactively provide a less-broken version :-) ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 12:56:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 12:56:27 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad In-Reply-To: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> References: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> Message-ID: <066.0e50ced56ad7b327c05a8eed7145460e@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13876 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's worth noting that `base-compat` doesn't backport data type definitions, so that's not a good home for it. I have no objections to ripping `WrappedMonad` out of `base` if that's what folks prefer. On the other hand, we do have a non-broken `WrappedMonoid` still in `Data.Semigroup`, so it feels somewhat strange to keep that but remove `WrappedMonoid`. But perhaps it's best to leave this discussion on the libraries mailing list... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 14:09:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 14:09:21 -0000 Subject: [GHC] #15090: Do more coercion optimisation on the fly Message-ID: <046.9667b6c209c395b52f77df698c889caa@haskell.org> #15090: Do more coercion optimisation on the fly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: Coercions | 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: -------------------------------------+------------------------------------- When studying #15019, I looked at `CoreOpt.pushCoValArg`. I saw lots of attempted decompositions in `pushCoValArg`, which were trying to do `decomposeFunCo` on {{{ C @g1 ; sym (C @g2) where axiom C a = a -> a }}} But the smart `mkNthCo` can't make progress on this, so we get {{{ Nth:2 (C @g1 ; sym (C @g2)) }}} and these things stack up if there is a chain of applications in `Simplify.simplCast`. The coercion optimiser will optimise this coercion to {{{ (g1 ; sym g2) -> (g1 ; sym g2) }}} and now the smart `mkNthCo` in `decomposeFunCo` will succeed. Possible idea: make this optimization part of `mkTransCo` so that it happens on the fly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 14:12:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 14:12:21 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.46c3f44693816a144a9e1373e4f344a9@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. Turns out that the T12227 regression was because I removed the `isReflexiveCo` at the end of `addCoerce`. This is embarrassingly delicate. Anyway, could you try this revised patch please? I've adjusted it a bit, and added comments. {{{ diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs index d92f6d7..f6a86f3 100644 --- a/compiler/simplCore/Simplify.hs +++ b/compiler/simplCore/Simplify.hs @@ -1209,40 +1209,73 @@ rebuild env expr cont ************************************************************************ -} +{- See Note [Optimising reflexivity] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +It's important (for compiler performance) to get rid of reflexivity as soon +as it appears. See Trac #11735, #14737, and #15019. + +In particular, we want to behave well on + + * e |> co1 |> co2 + where the two happent to cancel out entirely. That is quite common; + e.g. a newtype wrapping and unwrapping cancel + + + * (f |> co) @t1 @t2 ... @tn x1 .. xm + Here we wil use pushCoTyArg and pushCoValArg successively, which + build up NthCo stacks. Silly to do that if co is reflexive. + +However, we don't want to call isReflexiveCo too much, because it uses +type equality which is expensive on big types (Trac #14737 comment:7). + +A good compromise (determined experimentally) seems to be to call +isReflexiveCo + * when composing casts, and + * at the end + +In investigating this I saw missed opportunities for on-the-fly +coercion shrinkage. See Trac #15090. +-} + + simplCast :: SimplEnv -> InExpr -> Coercion -> SimplCont -> SimplM (SimplFloats, OutExpr) simplCast env body co0 cont0 = do { co1 <- {-#SCC "simplCast-simplCoercion" #-} simplCoercion env co0 - ; cont1 <- {-#SCC "simplCast-addCoerce" #-} addCoerce co1 cont0 + ; cont1 <- {-#SCC "simplCast-addCoerce" #-} + if isReflCo co1 + then return cont0 -- See Note [Optimising reflexivity] + else addCoerce co1 cont0 ; {-#SCC "simplCast-simplExprF" #-} simplExprF env body cont1 } where -- If the first parameter is Nothing, then simplifying revealed a -- reflexive coercion. Omit. - addCoerce0 :: Maybe OutCoercion -> SimplCont -> SimplM SimplCont - addCoerce0 Nothing cont = return cont - addCoerce0 (Just co) cont = addCoerce co cont + addCoerceM :: Maybe OutCoercion -> SimplCont -> SimplM SimplCont + addCoerceM Nothing cont = return cont + addCoerceM (Just co) cont = addCoerce co cont addCoerce :: OutCoercion -> SimplCont -> SimplM SimplCont - - addCoerce co1 (CastIt co2 cont) - = {-#SCC "addCoerce-simple-recursion" #-} - addCoerce (mkTransCo co1 co2) cont + addCoerce co1 (CastIt co2 cont) -- See Note [Optimising reflexivity] + | isReflexiveCo co' = return cont + | otherwise = addCoerce co' cont + where + co' = mkTransCo co1 co2 addCoerce co cont@(ApplyToTy { sc_arg_ty = arg_ty, sc_cont = tail }) | Just (arg_ty', m_co') <- pushCoTyArg co arg_ty = {-#SCC "addCoerce-pushCoTyArg" #-} - do { tail' <- addCoerce0 m_co' tail + do { tail' <- addCoerceM m_co' tail ; return (cont { sc_arg_ty = arg_ty', sc_cont = tail' }) } addCoerce co cont@(ApplyToVal { sc_arg = arg, sc_env = arg_se - , sc_dup = dup, sc_cont = tail }) + , sc_dup = dup, sc_cont = tail }) | Just (co1, m_co2) <- pushCoValArg co , Pair _ new_ty <- coercionKind co1 - , not (isTypeLevPoly new_ty) -- without this check, we get a lev-poly arg + , not (isTypeLevPoly new_ty) -- Without this check, we get a lev-poly arg -- See Note [Levity polymorphism invariants] in CoreSyn -- test: typecheck/should_run/EtaExpandLevPoly = {-#SCC "addCoerce-pushCoValArg" #-} - do { tail' <- addCoerce0 m_co2 tail + do { tail' <- addCoerceM m_co2 tail ; if isReflCo co1 then return (cont { sc_cont = tail' }) -- Avoid simplifying if possible; @@ -1260,15 +1293,10 @@ simplCast env body co0 cont0 , sc_cont = tail' }) } } addCoerce co cont - | isReflexiveCo co = {-#SCC "addCoerce-reflexive" #-} - return cont - | otherwise = {-#SCC "addCoerce-other" #-} - return (CastIt co cont) - -- It's worth checking isReflexiveCo. - -- For example, in the initial form of a worker - -- we may find (coerce T (coerce S (\x.e))) y - -- and we'd like it to simplify to e[y/x] in one round - -- of simplification + | isReflexiveCo co = return cont -- Having this at the end makes a huge + -- difference in T12227, for some reason + -- See Note [Optimising reflexivity] + | otherwise = return (CastIt co cont) simplArg :: SimplEnv -> DupFlag -> StaticEnv -> CoreExpr -> SimplM (DupFlag, StaticEnv, OutExpr) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 15:52:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 15:52:17 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.877496d8e67ce9ad43700cd9c9971929@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The trouble is that MkBar has an implicit forall's variable a, whose kind mentions an explicit type variable arg. Richard and I discussed this on Monday. Our conclusions * `Inferred` variables should always precede `Specified` ones. That is, do not top-sort * Idea: simply refrain from quantifying any inferred variables that mention specified ones. They'll get defaulted to `Any` which is probably fine. This refraining can readily be done in `candidatesQTyVarsOfType`. * Also came up: close over kinds once in `tyCoVarsOfType` instead of at every leaf. This is not just an efficiency issue: consider {{{ tyCoVarsOfType (forall a. b::a) }}} Richard is on the job -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 15:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 15:52:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c20b1af7d6a37f04e214ff4716e87822@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Trac #15076 is another example of the same phenomenon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 15:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 15:59:49 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.0c8662326cbbfb9e1cb6ed51d79bbb71@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is another example of #14880 The problem in comment:5 comes because when we kind-check foo's type signature, we generate this: {{{ foo :: forall {xx :: a}. forall (a :: Type) (f :: forall (x::a). Proxy @Type x -> Type) Proxy @(Proxy @a xx -> Type) (f @xx) -> () }}} Note that the `f` in `Proxy f` gets elaborated to `Proxy @.. (f @xx)`; that is `f` is instantiated with a fresh unification variable `xx`. But now we kind-generalise the result and put `xx` at the front. But `xx`'s kind mentions `a` -- disaster. Solution proposed for #14880: do not generalise over `xx`; instead default it to `Any`. So we'd get {{{ foo :: forall {xx :: a}. forall (a :: Type) (f :: forall (x::a). Proxy @Type x -> Type) Proxy @(Proxy @a (Any a) -> Type) (f @(Any a)) -> () }}} which is probably fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:01:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:01:26 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.81ad4b2fe69917400647ddb3e46ac7b3@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): And probably #14040 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:12:14 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.bdcaef4ab7d649a8e7827c59c1c989eb@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be good to get this done. e.g #13499 is another example of the typed-hole perf problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:15:52 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.6962d708e24b1035aa90f7005996d929@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, TypedHoles Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This bug still reproduces in HEAD, but it's impossible to debug until we solve the perf problem in #14969 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:33:34 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.132e926ebc58f43d0018a90f586200a3@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, TypedHoles Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, note that you can get this to panic in a reasonable amount of time on HEAD by passing the `-fno-show-valid-substitutions` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:38:24 -0000 Subject: [GHC] #15091: Better occurrence analysis for join points Message-ID: <046.b9552aa86f100d416522f1043145cf0b@haskell.org> #15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ let x = ... in join j y = x+y in case v of A -> x B -> j 1 C -> j 2 D -> 3 }}} What does `OccAnal` say about `x`'s usage? It says `ManyOccs`! But it's plain as a pikestaff that `x` is used at most once: * Either in the `A` branch, * or in the `B` or `C` branches via `j`. If instead we had inlined `j` we'd have {{{ let x = ... in join j y = x+y in case v of A -> x B -> x + 1 C -> x + 2 D -> 3 }}} and now it's all more obvious: `x`'s occurrence info should be `OneOcc { occ_one_br = False }`, not `ManyOccs`. Does this matter? Not a great deal, but there is a reason for having `OneOcc` with `occ_one_br = False`, and it seems a shame not to take advantage. One case in point is the definition of `SimplUtils.isExitJoinId {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Something does not cease to be an exit-join-point if it is mentioned in multiple places as above. Another use for this info is `postInlineUnconditionally`. Could we improve this situation? I think it'd be quite easy. For non- recursive join points `j = rhs` * Gather occurrence info from the RHS * Bind `j` to its occurrence info * Unleash that occurrence info at each jump-site for `j`, just as if it had been inlined. See Trac #14152, comment:40. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:39:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:39:19 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.d685af6d094f51f183108054d5b2048f@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > All join-point should have OneOcc Aha. They should, but indeed they don't. I've created Trac #15091 to fix this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 16:44:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 16:44:22 -0000 Subject: [GHC] #14955: Musings on manual type class desugaring In-Reply-To: <049.12855af11ea5950a6983dee948966231@haskell.org> References: <049.12855af11ea5950a6983dee948966231@haskell.org> Message-ID: <064.a50890c3c406ce332a0c156741cb09c6@haskell.org> #14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3d38e8284b7382844f9862e8d8afbae9c7248b09/ghc" 3d38e82/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3d38e8284b7382844f9862e8d8afbae9c7248b09" Do not unpack class dictionaries with INLINABLE Matthew Pickering uncovered a bad performance hole in the way that single-method dictionaries work, described in Trac #14955. See Note [Do not unpack class dictionaries] in WwLib. I tried to fix this 6 years ago, but got it slightly wrong. This patch fixes it, which makes a dramatic improvement in the test case. Nofib highlights: not much happening: Program Size Allocs Runtime Elapsed TotalMem ----------------------------------------------------------------- VSM -0.3% +2.7% -7.4% -7.4% 0.0% cacheprof -0.0% +0.1% +0.3% +0.7% 0.0% integer -0.0% +1.1% +7.5% +7.5% 0.0% tak -0.1% -0.2% 0.024 0.024 0.0% ----------------------------------------------------------------- Min -4.4% -0.2% -7.4% -7.4% -8.0% Max +0.6% +2.7% +7.5% +7.5% 0.0% Geom Mean -0.1% +0.0% +0.1% +0.1% -0.2% I investigated VSM. The patch unpacks class dictionaries a bit more than before (i.e. does so if there is no INLINABLE pragma). And that gives better code in VSM (less dictionary selection etc), but one closure gets one word bigger. I'll accept these changes in exchange for more robust performance. Some ghci.debugger output wobbled around (order of bindings being displayed). I have no idea why; but I accepted the changes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 17:17:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 17:17:31 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.25c0486a43e029d70ed63c8ac55335b8@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Yes! I'll try to get the patch ready for inclusion this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 17:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 17:18:28 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.8d36336ecf04de10712f15b2ab4d3664@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: #14200 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: In my opinion, there are two reasonable ways forward: 1. Adopt `Monad` of no `return`, and deprecate and remove `WrappedMonad` altogether. 2. Change the definition of `pure` for `WrappedMonad` back to using `return`, which will make it usable, among other things, for defining `Functor` and `Applicative` instances using `DerivingVia`. 1 may happen (I personally hope so), but probably not this year. I don't personally see any serious downside to proceeding with 2 for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 18:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 18:16:13 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.08d86e6098fa9ad15d22753839a8eef3@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14200 | Differential Rev(s): Phab:D4638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4638 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 18:46:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 18:46:10 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.bf640c104bfd037a11ed7d783df7dbfc@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3416, Wiki Page: | Phab:D4638 -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D3416 => Phab:D3416, Phab:D4638 Comment: Zemyla, in an amazing coincidence of timing, I happened to write something very similar to your first instance in Phab:D4638 just now. I think it makes sense to use `foldr` to fold over the first argument. Unfortunately, the `build` is a bit trickier, because it will end up copying the second list if it doesn't fuse away. I'm not sure if it's possible to work around that issue with `RULES`. Appends are generally handled by `augment`, but that mechanism isn't powerful enough for what we're doing here because it leaves no room to use an accumulated count in the tail. As for the hand- unboxing, I'd only go for that if GHC proves incapable of unboxing on its own; it's really quite good at that most of the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 18:46:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 18:46:24 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.7bbbaa8bc06c57bbcc38443c5ea7c869@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3416, Wiki Page: | Phab:D4638 -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 20:56:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 20:56:04 -0000 Subject: [GHC] #14955: Musings on manual type class desugaring In-Reply-To: <049.12855af11ea5950a6983dee948966231@haskell.org> References: <049.12855af11ea5950a6983dee948966231@haskell.org> Message-ID: <064.a8bc46cbf7d285efd6ba017ce1a5dc68@haskell.org> #14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: SpecConstr 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): * status: new => closed * resolution: => fixed Comment: Thanks for highlighting this, Matthew. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 21:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 21:05:14 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.61f3b4625e9fbcfa0372d7d714972ef2@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I have a fix [https://github.com/goldfirere/ghc/commit/7386ea571cdd50d45432e20a5318e7e870f0176b here], but it causes a failure in, e.g., indexed- types/should_compile/T12369. Haven't had time to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 21:26:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 21:26:16 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.c231ebc223254ae5689fdd6b9e6e8bb4@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, TypedHoles Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Ryan. I know what is happening here. Here's the code for typechecking `static e` {{{ tcExpr (HsStatic fvs expr) res_ty = do { res_ty <- expTypeToType res_ty ; (co, (p_ty, expr_ty)) <- matchExpectedAppTy res_ty ; (expr', lie) <- captureConstraints $ addErrCtxt (hang (text "In the body of a static form:") 2 (ppr expr) ) $ tcPolyExprNC expr expr_ty -- Check that the free variables of the static form are closed. -- It's OK to use nonDetEltsUniqSet here as the only side effects of -- checkClosedInStaticForm are error messages. ; mapM_ checkClosedInStaticForm $ nonDetEltsUniqSet fvs -- Require the type of the argument to be Typeable. -- The evidence is not used, but asking the constraint ensures that -- the current implementation is as restrictive as future versions -- of the StaticPointers extension. ; typeableClass <- tcLookupClass typeableClassName ; _ <- emitWantedEvVar StaticOrigin $ mkTyConApp (classTyCon typeableClass) [liftedTypeKind, expr_ty] -- Insert the constraints of the static form in a global list for later -- validation. ; emitStaticConstraints lie -- Wrap the static form with the 'fromStaticPtr' call. ; fromStaticPtr <- newMethodFromName StaticOrigin fromStaticPtrName p_ty ; let wrap = mkWpTyApps [expr_ty] ; loc <- getSrcSpanM ; return $ mkHsWrapCo co $ HsApp noExt (L loc $ mkHsWrap wrap fromStaticPtr) (L loc (HsStatic fvs expr')) } }}} Notice that the constraints arising from `e` are captured as `lie`, and given to `emitStaticConstraints`, which puts them in a top-level bag of consraints. The idea is that we should not be using any local (dynamic) givens in a `static` construct. But in doing so, we also put those coustraints outside the scope of any skolems, in this case the `a`. So we end up with a constraint like {{{ wanted = WC {wc_simple = [WD] __a1hn {0}:: t_a1hm[tau:2] (CHoleCan: ExprHole(_)) wc_impl = Implic { TcLevel = 2 Skolems = a_a1hi[sk:2] No-eqs = False Status = Unsolved Given = $dTypeable_a1hk :: Typeable a_a1hi[sk:2] Wanted = WC {wc_simple = [WD] $dTypeable_a1ho {0}:: Typeable (a_a1hi[sk:2] -> a_a1hi[sk:2]) (CNonCanonical) [WD] $dIsStatic_a1hv {0}:: GHC.StaticPtr.IsStatic StaticPtr (CNonCanonical)} Binds = EvBindsVar Needed inner = [] Needed outer = [] the type signature for: f :: forall a. Typeable a => StaticPtr (a -> a) }} }}} Notice that `CHoleCan` outside the scope of the implication. This all smells wrong, but I don't immediately know how to fix it. We want the constraints from `e` to be inside an implication shorn of any givens, and that's not very easy to do. The story for `static` and constraints, or even polymorphism, is is not well worked out. Even top-level values with type `forall a. Static (a->a)` is suspiciuos, although useful. So rather than trying some kluge to fix it I think I'll leave the embarrassing crash as an inceniive to work out what the Right Thing might be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 21:55:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 21:55:58 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.028fdc8fb001d012001c9a4885e113a7@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe #14887 too! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 22:23:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 22:23:18 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.2106569a87828aaaf974e4c7707e6bf5@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: In Simon's example, {{{#!hs f (toList -> []) = e1 f (toList -> (a:as)) = e2 }}} I don't see how it's at all relevant that `toList` is from an `IsList` instance. I imagine we ''always'' want to common up view patterns using the same function for coverage checking. For example, given {{{#!hs f (g -> P1) = e1 f P2 = e2 f (g -> P3) = e3 }}} I imagine we want to transform that to something like {{{#!hs f x | P1 <- gx = e1 | P2 <- x = e2 | P3 <- gx = e3 where gx = g x }}} when performing coverage checks. I don't know how the details work out for the pattern checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 22:23:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 22:23:47 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.f3fd38a0492dc77bf514cc72c5f8eab3@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's what is going on with: {{{ foo2 :: forall (k :: Type) (e :: Proxy (a :: k)). Int }}} In `TcHsType.tc_hs_sig_type_and_gen` we see {{{ tc_hs_sig_type_and_gen skol_info (HsIB { hsib_vars = sig_vars , hsib_body = hs_ty }) kind = do { (tkvs, ty) <- solveEqualities $ tcImplicitTKBndrs skol_info sig_vars $ tc_lhs_type typeLevelMode hs_ty kind }}} Here `sig_vars` is just `a`. Now `tcImplicitTKBndrs` gives `a` a kind `k0` (a unification variable), so we attempt to kind-check {{{ forall (a::k0). forall (k :: Type) (e :: Proxy (a :: k)). Int }}} But that requires `k0 ~ k`, which is a skolem-escape problem. We end up trying (and failing) solve the constraint {{{ Implic { TcLevel = 2 Skolems = (a_avH[sk:2] :: k_aZs[tau:2]) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_impl = Implic { TcLevel = 3 Skolems = k_aZp[sk:3] (e_aZq[sk:3] :: Proxy k_aZp[sk:3] (a_avH[sk:2] |> {co_aZC})) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [WD] hole{co_aZC} {0}:: (k_aZs[tau:2] :: *) GHC.Prim.~# (k_aZp[sk:3] :: *) (CNonCanonical)} }}} Here `k0` is `k_aZs`, and it is (rightly) untouchable inside the level-3 implication. Hence the error message. I have not yet thought about what to do. Richard may have some ideas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 22:45:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 22:45:44 -0000 Subject: [GHC] #15092: Optionally bounds-check primops Message-ID: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> #15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be awfully nice if there were a way to optionally get bounds- checked versions of array primitives. The idea would be that if GHC is compiled with a bounds-checking option, then the code generator would use primops that verify indices are in bounds. Based on [https://mail.haskell.org/pipermail/haskell-cafe/2018-April/128992.html a question by Henning Thielemann], I suspect such a feature would get some use. The biggest challenge: `SomeException`, `Typeable`, `Show`, `String`, `CallStack`, etc., all live in an entirely different universe than the primops, so it's not exactly obvious how to get started. I don't know if it would be possible to inject references to such things into a lower level. Sounds hard, but maybe it's possible. An alternative, probably much simpler, approach would be to crash hard with an error message instead of trying to throw a proper exception. Ideally, the error message would include the name of the primop and (for modules compiled with profiling) some call stack info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 23:03:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 23:03:13 -0000 Subject: [GHC] #15083: cannot install GHC on CentOS In-Reply-To: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> References: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> Message-ID: <060.b9198ea83e18fd66cb806a07c5d01453@haskell.org> #15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 kbrown: Old description: > This is the information of my system: > > {{{ > > cat /etc/*release > CentOS Linux release 7.4.1708 (Core) > NAME="CentOS Linux" > VERSION="7 (Core)" > ID="centos" > ID_LIKE="rhel fedora" > VERSION_ID="7" > PRETTY_NAME="CentOS Linux 7 (Core)" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:centos:centos:7" > HOME_URL="https://www.centos.org/" > BUG_REPORT_URL="https://bugs.centos.org/" > > CENTOS_MANTISBT_PROJECT="CentOS-7" > CENTOS_MANTISBT_PROJECT_VERSION="7" > REDHAT_SUPPORT_PRODUCT="centos" > REDHAT_SUPPORT_PRODUCT_VERSION="7" > }}} > > I want to build a Stack project on this system, but I receive an > "impossible" error even when I try to build a trivial project. > > {{{ > >wget https://www.stackage.org/stack/linux-x86_64-static > >tar -xzf linux-x86_64-static > > cp stack-1.6.5-linux-x86_64-static/stack .local/bin/ > > > stack new stacktest > Downloading template "new-template" to create project "stacktest" in > stacktest/ ... > > The following parameters were needed by the template but not provided: > author-email, author-name, category, copyright, github-username > You can provide them in /home/users/ksb/.stack/config.yaml, like this: > templates: > params: > author-email: value > author-name: value > category: value > copyright: value > github-username: value > Or you can pass each one as parameters like this: > stack new stacktest new-template -p "author-email:value" -p "author- > name:value" -p "category:value" -p "copyright:value" -p "github- > username:value" > > Looking for .cabal or package.yaml files to use to init the project. > Using cabal packages: > - stacktest/ > > Selecting the best among 13 snapshots... > > * Matches lts-11.6 > > Selected resolver: lts-11.6 > Initialising configuration using resolver: lts-11.6 > Total number of user packages considered: 1 > Writing configuration to file: stacktest/stack.yaml > All done. > > > stack build > > [1 of 2] Compiling Main ( /home/users/ksb/.stack/setup-exe- > src/setup-mPHDZzAJ.hs, /home/users/ksb/.stack/setup-exe-src/setup- > mPHDZzAJ.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-unknown-linux): > toStgWord: Unknown platformWordSize: 0 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > -- While building simple Setup.hs using: > /home/users/ksb/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc > -rtsopts -threaded -clear-package-db -global-package-db -hide-all- > packages -package base -main-is StackSetupShim.mainOverride -package > Cabal-2.0.1.0 /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.hs > /home/users/ksb/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -o > /home/users/ksb/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal- > simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 > Process exited with code: ExitFailure 1 > > }}} > > Can you help me identify why this build failed? New description: This is the information of my system: {{{ > cat /etc/*release CentOS Linux release 7.4.1708 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" >cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz stepping : 1 microcode : 0xb000025 cpu MHz : 1200.035 cache size : 20480 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single intel_pt spec_ctrl ibpb_support tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts bogomips : 4200.32 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: }}} I want to build a Stack project on this system, but I receive an "impossible" error even when I try to build a trivial project. {{{ >wget https://www.stackage.org/stack/linux-x86_64-static >tar -xzf linux-x86_64-static > cp stack-1.6.5-linux-x86_64-static/stack .local/bin/ > stack new stacktest Downloading template "new-template" to create project "stacktest" in stacktest/ ... The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username You can provide them in /home/users/ksb/.stack/config.yaml, like this: templates: params: author-email: value author-name: value category: value copyright: value github-username: value Or you can pass each one as parameters like this: stack new stacktest new-template -p "author-email:value" -p "author- name:value" -p "category:value" -p "copyright:value" -p "github- username:value" Looking for .cabal or package.yaml files to use to init the project. Using cabal packages: - stacktest/ Selecting the best among 13 snapshots... * Matches lts-11.6 Selected resolver: lts-11.6 Initialising configuration using resolver: lts-11.6 Total number of user packages considered: 1 Writing configuration to file: stacktest/stack.yaml All done. > stack build [1 of 2] Compiling Main ( /home/users/ksb/.stack/setup-exe-src /setup-mPHDZzAJ.hs, /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): toStgWord: Unknown platformWordSize: 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building simple Setup.hs using: /home/users/ksb/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-2.0.1.0 /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.hs /home/users/ksb/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -o /home/users/ksb/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 Process exited with code: ExitFailure 1 }}} Can you help me identify why this build failed? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 26 23:13:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Apr 2018 23:13:16 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.d667031bb88c31fc1c197c7fd0d4c77c@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Today, the failures are up to: TEST="T13658 T14779a T14779b T14868 T14955 debug" {{{ -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O cd "./perf/should_run/T14955.run" && ./T14955 +RTS -V0 -tT14955.stats --machine-readable -RTS Actual stdout output differs from expected: diff -uw "./perf/should_run/T14955.run/T14955.stdout.normalised" "./perf/should_run/T14955.run/T14955.run.stdout.normalised" --- ./perf/should_run/T14955.run/T14955.stdout.normalised 2018-04-27 00:10:03.056784655 +0100 +++ ./perf/should_run/T14955.run/T14955.run.stdout.normalised 2018-04-27 00:10:03.060784652 +0100 @@ -1 +1 @@ - +True *** unexpected failure for T14955(normal) Unexpected results from: TEST="T14955" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 02:58:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 02:58:33 -0000 Subject: [GHC] #14421: LambdaCase should be suggested if it is used but not enabled In-Reply-To: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> References: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> Message-ID: <066.c32b54cc19d5c64eea33afbf50454d1c@haskell.org> #14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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:D4260 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => closed * differential: => Phab:D4260 * resolution: => fixed Comment: This ticket has already implemented in the `BlockArguments` patch, which will be included in ghc-8.6.1. With ghc-HEAD, you will get: {{{#!hs Prelude> :t \case (_,_) -> () :1:2: error: Illegal lambda-case (use -XLambdaCase) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 02:58:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 02:58:57 -0000 Subject: [GHC] #14421: LambdaCase should be suggested if it is used but not enabled In-Reply-To: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> References: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> Message-ID: <066.b7fa033c89ea3b678eb30c2fda960cd2@haskell.org> #14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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:D4260 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 03:01:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 03:01:28 -0000 Subject: [GHC] #14421: LambdaCase should be suggested if it is used but not enabled In-Reply-To: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> References: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> Message-ID: <066.ba067268a8597d7e4eba5aac836be510@haskell.org> #14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/ParserNoLambdaCase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4260 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * testcase: => parser/should_fail/ParserNoLambdaCase * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 06:24:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 06:24:39 -0000 Subject: [GHC] #15092: Optionally bounds-check primops In-Reply-To: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> References: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> Message-ID: <060.e27b11c31e87c1a2e9bdb67bfa25dd51@haskell.org> #15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I think a hard crash is completely appropriate. Bound violations are programming errors thus there is no way to safely recover from them, anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 07:26:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 07:26:33 -0000 Subject: [GHC] #15092: Optionally bounds-check primops In-Reply-To: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> References: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> Message-ID: <060.9447b2e3246d20f331ba302cb6680f39@haskell.org> #15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 Lemming]: > I think a hard crash is completely appropriate. Bound violations are programming errors thus there is no way to safely recover from them, anyway. My concerns about the "hard crash" approach: the error messages may not be as informative as one might wish, it may be tough to get the error messages in some environments, and I don't know if there would be any challenges ensuring that other application threads get killed. But I do think it would be a lot better to have that as an option than to have nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 07:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 07:56:53 -0000 Subject: [GHC] #15092: Optionally bounds-check primops In-Reply-To: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> References: <045.7c74e2e48c0a0228d94551b80a4b0426@haskell.org> Message-ID: <060.6832d6e72896a075ed6e5a08cdbdb1b1@haskell.org> #15092: Optionally bounds-check primops -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I also frequently need this when debugging memory corruptions (e.g. #15038). > The biggest challenge: SomeException, Typeable, Show, String, CallStack, etc. Why is this a challenge? I don't see the relation between with these type classes and array operations. > I think a hard crash is completely appropriate. Bound violations are programming errors thus there is no way to safely recover from them, anyway. Agreed, but I think there's another approach: raising an exception. We already raise exceptions for runtime errors like non-exhaustive pattern mathing. We could do the same. We already have the type defined: http://hackage.haskell.org/package/base-4.11.1.0/docs/Control- Exception.html#t:ArrayException For my use case, even just a "out of bounds access!" message would do it so I don't feel strongly either way. Note that currently GHC (in DWARF version) already prints the C stack trace on panic: {{{ Main: internal error: evacuate(static): strange closure type 16583 Stack trace: 0x4b4dfb set_initial_registers (rts/Libdw.c:288.0) 0x7f37ccfb3558 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.165.so) 0x7f37ccfb2faf (null) (/usr/lib/x86_64-linux- gnu/libdw-0.165.so) 0x7f37ccfb32d7 dwfl_getthreads (/usr/lib/x86_64-linux- gnu/libdw-0.165.so) 0x7f37ccfb38e0 dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.165.so) 0x4b538d libdwGetBacktrace (rts/Libdw.c:259.0) 0x49ce1c rtsFatalInternalErrorFn (rts/RtsMessages.c:172.0) 0x49cfad barf (rts/RtsMessages.c:48.0) 0x4a162e evacuate (includes/rts/storage/Block.h:175.0) 0x4b765b scavenge_loop (rts/sm/Scav.c:1830.0) 0x4a0532 GarbageCollect (rts/sm/GC.c:1423.0) 0x49bb87 scheduleDoGC (rts/Schedule.c:1814.0) 0x49c8c4 scheduleWaitThread (rts/Schedule.c:558.0) 0x49d450 rts_evalLazyIO (rts/RtsAPI.c:531.0) 0x49d75b hs_main (rts/RtsMain.c:73.0) 0x40d6aa (null) (/home/omer/haskell/corrupted-memory- example/Main) 0x7f37ccbd7830 __libc_start_main (../csu/libc- start.c:325.0) 0x4042f9 _start (/home/omer/haskell/corrupted-memory- example/Main) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 3391 abort (core dumped) ./Main }}} So we get some information for free already. > My concerns about the "hard crash" approach: the error messages may not be as informative as one might wish I'm curious what kind of error messages you'd like to get? I think the main problem is for "out of line" array operations like `copyArray#` we'll need one more variant of RTS, so longer GHC boot times, more code to distribute etc. Not sure how to avoid this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 08:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 08:35:36 -0000 Subject: [GHC] #15091: Better occurrence analysis for join points In-Reply-To: <046.b9552aa86f100d416522f1043145cf0b@haskell.org> References: <046.b9552aa86f100d416522f1043145cf0b@haskell.org> Message-ID: <061.1fccd8de0a6895b00867dffd7a254cbf@haskell.org> #15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: Sounds a lot like how the demand analyser always uses LetDown to handle join points. `Note [Demand analysis for join points]` might be relevant. I found that occurrence analysis, usage analysis and call arity (to an extent) are strongly related, as they all try to compute max cardinality info. So they should agree on how to handle join points. ticket:13479#comment:10 hints about this for Call Arity. Appearently, `Note [Call Arity and Join Points]` explains we currently don't do this because of complexity concerns, probably because Call Arity has no analogue of LetDown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 08:40:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 08:40:40 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.329bda5212fd7590f2b16e9fa283570a@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:7 simonpj]: Thanks for your explanation and analysis, Simon. I agree to add a note to explain this condition. Now I have some other thought with the `ListPat` case of `translatePat`. > You are checking that the function actually has type [t1] -> [t2], where normalise t1 = normalise t2. I think in fact we don't need to do the check. For `ListPat x lpats elem_ty (Just (pat_ty, _to_list))`, we know the `_to_list` have type: {{{ toList :: l -> [Item l] }}} If we know the `pat_ty` (the `l` in toList's signature) is `[a]` (the List type), then we can conclude that `Item l = a`, in other words, `norm_elem_ty = norm_e_ty`. Because in `instance IsList [a]`, we have `type (Item [a]) = a`. Although we can give an instance IsList [Int] (more specific than the default IsList [a]), we can't overwrite the type family instance. The original comment says: > {{{ > -- We have to ensure that the element types are exactly the same. > -- Otherwise, one may give an instance IsList [Int] (more specific than > -- the default IsList [a]) with a different implementation for `toList' > }}} However we can't achieve this goal without check the type of `_to_list`. In practice, we almost never define more specific IsList instance like `instance IsList [Int]`, we don't need to concern that case. So we can simplify the code as {{{#!hs ListPat x lpats elem_ty (Just (pat_ty, _to_list)) | Just e_ty <- splitListTyConApp_maybe pat_ty -> translatePat fam_insts (ListPat x lpats e_ty Nothing) | otherwise -> mkCanFailPmPat pat_ty }}} Or should be check whether the type of `_to_list` is `[a] -> [a]` (the most general type) ? I don't think it's necessary for practical Haskell code. **I'm not sure if I understand this correctly.** Another silly question is that I still can't see why we need to concern about the view pattern for exhaustiveness checking of overloaded list. I think the `toList` and the `[a]` instance of `IsList` are different with ordinary view functions in view pattern. I will mention this in the note. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 08:43:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 08:43:35 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.1e03bc33a0311ddc31b1b94daec98675@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 10:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 10:15:27 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support Message-ID: <049.900d127190549a522493fcc24922ad0e@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CI | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser. Instead, you can output the test results as JUnit XML which then CircleCI can slurp up and present nicely. https://circleci.com/docs/2.0 /configuration-reference/#store_test_results There is a python library which makes it easy to generate this output. https://github.com/kyrus/python-junit-xml Even better, an actual python testing library could be used which could automatically output this information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 10:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 10:30:44 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.aed536126ebab9afff84051f8106e2d5@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): There are also ways to do this in Haskell. But not without incurring extra dependencies. See e.g. http://hackage.haskell.org/package/tasty-jenkins- xml and http://hackage.haskell.org/package/hspec-jenkins. Perhaps inspiration for generating the requisite XML from the current test harness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 10:31:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 10:31:17 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.61b581c2fddcb791fb168a00417c7dbd@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI 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 mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 12:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 12:28:08 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.a93e7d32d4b0e9f32395e85a9f880fa4@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 osa1): I spent some more time debugging this. Basically at one point the GC overwrites an info table, messing up the type field. {{{ $ gdb ./Main -nh Reading symbols from ./Main...done. (gdb) start Temporary breakpoint 1 at 0x40d29e Starting program: /home/omer/haskell/corrupted-memory-example/Main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, 0x000000000040d29e in main () }}} Now I can see that type of an info table is `CONSTR_2_0`: {{{ (gdb) print get_itbl(0x9815f8)->type $1 = 4 }}} Now continue until it crashes: {{{ (gdb) c Continuing. Main: internal error: evacuate(static): strange closure type 16580 (GHC version 8.5.20180425 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6e90428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. }}} and at this point the same info table has wrong type field: {{{ (gdb) print get_itbl(0x9815f8)->type $2 = 16580 }}} Adding a watchpoint to this location causes gdb to leak memory so I couldn't do it from the start. I realized that this happens when evacuate is called 143851nd time so I run the program until that call, then enable the watchpoint, and continue. First hit is {{{ Watchpoint 3: get_itbl(0x9815f8)->type Old value = 4 New value = 0 evacuate_static_object (link_field=0x9815f8, q=0x9815f0) at rts/sm/Evac.c:347 347 gct->static_objects = (StgClosure *)new_list_head; (gdb) bt #0 evacuate_static_object (link_field=0x9815f8, q=0x9815f0) at rts/sm/Evac.c:347 #1 0x00000000008e79e0 in evacuate (p=0x981608) at rts/sm/Evac.c:546 #2 0x0000000000910c29 in scavenge_static () at rts/sm/Scav.c:1831 #3 0x00000000009111f8 in scavenge_loop () at rts/sm/Scav.c:2185 #4 0x00000000008e34bb in scavenge_until_all_done () at rts/sm/GC.c:1092 #5 0x00000000008e2118 in GarbageCollect (collect_gen=1, do_heap_census=false, gc_type=0, cap=0xad4080 , idle_cap=0x0) at rts/sm/GC.c:418 #6 0x00000000008d4dfb in scheduleDoGC (pcap=0x7fffffffd630, task=0xaebd00, force_major=false) at rts/Schedule.c:1799 #7 0x00000000008d4347 in schedule (initialCapability=0xad4080 , task=0xaebd00) at rts/Schedule.c:545 #8 0x00000000008d57a1 in scheduleWaitThread (tso=0x4200105388, ret=0x0, pcap=0x7fffffffd720) at rts/Schedule.c:2533 #9 0x00000000008d7997 in rts_evalLazyIO (cap=0x7fffffffd720, p=0x981710, ret=0x0) at rts/RtsAPI.c:530 #10 0x00000000008d808a in hs_main (argc=1, argv=0x7fffffffd918, main_closure=0x981710, rts_config=...) at rts/RtsMain.c:72 #11 0x000000000040d39a in main () }}} Here it gets overwritten to `0`. When I continue it gets overwritten one more time: {{{ (gdb) c Continuing. Watchpoint 3: get_itbl(0x9815f8)->type Old value = 0 New value = 16580 scavenge_static () at rts/sm/Scav.c:1789 1789 gct->scavenged_static_objects = flagged_p; (gdb) bt #0 scavenge_static () at rts/sm/Scav.c:1789 #1 0x00000000009111f8 in scavenge_loop () at rts/sm/Scav.c:2185 #2 0x00000000008e34bb in scavenge_until_all_done () at rts/sm/GC.c:1092 #3 0x00000000008e2118 in GarbageCollect (collect_gen=1, do_heap_census=false, gc_type=0, cap=0xad4080 , idle_cap=0x0) at rts/sm/GC.c:418 #4 0x00000000008d4dfb in scheduleDoGC (pcap=0x7fffffffd630, task=0xaebd00, force_major=false) at rts/Schedule.c:1799 #5 0x00000000008d4347 in schedule (initialCapability=0xad4080 , task=0xaebd00) at rts/Schedule.c:545 #6 0x00000000008d57a1 in scheduleWaitThread (tso=0x4200105388, ret=0x0, pcap=0x7fffffffd720) at rts/Schedule.c:2533 #7 0x00000000008d7997 in rts_evalLazyIO (cap=0x7fffffffd720, p=0x981710, ret=0x0) at rts/RtsAPI.c:530 #8 0x00000000008d808a in hs_main (argc=1, argv=0x7fffffffd918, main_closure=0x981710, rts_config=...) at rts/RtsMain.c:72 #9 0x000000000040d39a in main () }}} The value `16580` is what we see in the error message. I don't know if this is a problem with GC, maybe it's something wrong with the code gen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 15:02:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 15:02:52 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.38d6f1f994645cc12f7aaeac14f0763f@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Phab:D4626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by isovector): * status: new => patch * differential: => Phab:D4626 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 15:56:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 15:56:19 -0000 Subject: [GHC] #14955: Musings on manual type class desugaring In-Reply-To: <049.12855af11ea5950a6983dee948966231@haskell.org> References: <049.12855af11ea5950a6983dee948966231@haskell.org> Message-ID: <064.f64ced78fc9118d6220df5938882abd2@haskell.org> #14955: Musings on manual type class desugaring -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"56bbe1e4aac9eb3e722db64f628474070d4b80d4/ghc" 56bbe1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="56bbe1e4aac9eb3e722db64f628474070d4b80d4" Add missing stdout file for T14955 Accidentally omitted from Trac #14955 commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 16:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 16:21:29 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.53e644fdff7da31743c5c46229d55067@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0c01224bb95b3c0d6730ededaf04c9ab0892e297/ghc" 0c01224b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c01224bb95b3c0d6730ededaf04c9ab0892e297" Refactor tcExtendLocalFamInst a bit This patch just pulls out FamInst.loadDependentFamInstModules as a separate function, and adds better comments. Provoked by Trac #14759, comment:10. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 16:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 16:21:29 -0000 Subject: [GHC] #14149: Tyepchecker generates top-level unboxed coercion In-Reply-To: <046.cedaffee7ff4ab48fd36761ff9f90f4f@haskell.org> References: <046.cedaffee7ff4ab48fd36761ff9f90f4f@haskell.org> Message-ID: <061.2c10e8aac9c5da8050362730cf5236b1@haskell.org> #14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T14149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"08003e7f4abafb0c9fe084e4670122ce67cf45dd/ghc" 08003e7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08003e7f4abafb0c9fe084e4670122ce67cf45dd" Make out-of-scope errors more prominent Generally, when the type checker reports an error, more serious ones suppress less serious ones. A "variable out of scope" error is arguably the most serious of all, so this patch moves it to the front of the list instead of the end. This patch also fixes Trac #14149, which had -fdefer-out-of-scope-variables, but also had a solid type error. As things stood, the type error was not reported at all, and compilation "succeeded" with error code 0. Yikes. Note that - "Hole errors" (including out of scope) are never suppressed. (maybeReportHoleError vs maybeReportError in TcErorrs) They can just get drowned by the noise. - But with the new orientation, out of scope errors will suppress type errors. That would be easy to change. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 16:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 16:21:29 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.1b4723c543001d66364c415c67406af0@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6da5b8772d512e2fb61730367f5258303e008ab4/ghc" 6da5b87/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6da5b8772d512e2fb61730367f5258303e008ab4" Better linting for types Trac #15057 described deficiencies in the linting for types involving type synonyms. This patch fixes an earlier attempt. The moving parts are desrcribed in Note [Linting type synonym applications] Not a big deal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 16:28:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 16:28:07 -0000 Subject: [GHC] #15057: Lint types created by newFamInst In-Reply-To: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> References: <050.7805acab12d772d3b3d69b9f9a4ac854@haskell.org> Message-ID: <065.913884912aa91530caf3cfdc5f36685e@haskell.org> #15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15012 | Differential Rev(s): Phab:D4611 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 16:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 16:45:15 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.918faa84cfbb586da45ee0f93ee220c7@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): How is this going? I don't mean to steal it out from under you, but if this is caught behind other priorities, it would make a great warm-up exercise for my GSoC student. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 17:31:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 17:31:46 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows Message-ID: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows --------------------------------+--------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- I got this error when building with 32-bit ghc 8.4.2 on appveyor: {{{ -- While building custom Setup.hs for package hledger-lib-1.9.99 using: C:\sr\setup-exe-cache\i386-windows\Cabal- simple_Z6RU0evB_2.2.0.1_ghc-8.4.2.exe --builddir=.stack-work\dist\ba067387 build lib:hledger-lib --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: C:\pr\.stack-work\logs\hledger- lib-1.9.99.log Configuring hledger-lib-1.9.99... Preprocessing library for hledger-lib-1.9.99.. Building library for hledger-lib-1.9.99.. [ 1 of 48] Compiling Hledger.Utils.Color ( Hledger\Utils\Color.hs, .stack-work\dist\ba067387\build\Hledger\Utils\Color.o ) [ 2 of 48] Compiling Hledger.Utils.Test ( Hledger\Utils\Test.hs, .stack-work\dist\ba067387\build\Hledger\Utils\Test.o ) [ 3 of 48] Compiling Hledger.Utils.UTF8IOCompat ( Hledger\Utils\UTF8IOCompat.hs, .stack- work\dist\ba067387\build\Hledger\Utils\UTF8IOCompat.o ) [ 4 of 48] Compiling Hledger.Utils.Regex ( Hledger\Utils\Regex.hs, .stack-work\dist\ba067387\build\Hledger\Utils\Regex.o ) [ 5 of 48] Compiling Hledger.Utils.Tree ( Hledger\Utils\Tree.hs, .stack-work\dist\ba067387\build\Hledger\Utils\Tree.o ) [ 6 of 48] Compiling Hledger.Data.Types ( Hledger\Data\Types.hs, .stack-work\dist\ba067387\build\Hledger\Data\Types.o ) ghc.EXE: unable to load package `clock-0.7.2' ghc.EXE: | C:\sr\snapshots\673e3da0\lib\i386-windows- ghc-8.4.2\clock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU\HSclock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU.o: unknown symbol `___divmoddi4' Command exited with code 1 APPVEYOR_SAVE_CACHE_ON_ERROR is set to 'true' - cache will be updated }}} https://ci.appveyor.com/project/simonmichael/hledger/build/master-404 We think this is related: https://github.com/zfsonlinux/zfs/issues/6417 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 18:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 18:47:53 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows Message-ID: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On appveyor I had a problem building pretty-show: {{{ -- While building custom Setup.hs for package pretty-show-1.7 using: C:\sr\setup-exe-cache\i386-windows\Cabal- simple_Z6RU0evB_2.2.0.1_ghc-8.4.2.exe --builddir=.stack-work\dist\ba067387 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure (-1073741819) }}} More details at https://github.com/yav/pretty-show/issues/27 . Converting the (otherwise standard) Setup.lhs to a non-literate Setup.hs seemed to fix it. Switching to 64-bit GHC seemed to also fix it (the Setup.lhs worked with 64-bit GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 22:22:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 22:22:02 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.aeeccd3f45aef8d3827d4142af4d19c5@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path ---------------------------------+---------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10762 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by lehins): I can confirm this issue with Cyrillic characters on Windows 7 with latest GHC. If locale set to Russian through the control panel everything works fine, but changing the codepage does break {{{ghc-pkg}}} {{{ PS C:\Users\Алексей\ghc-8.4.2\bin> chcp 437 Active code page: 437 PS C:\Users\???????\ghc-8.4.2\bin> .\ghc-pkg.exe list C:\Users\ghc-pkg.exe: : commitBuffer: invalid argument (invalid character) PS C:\Users\???????\ghc-8.4.2\bin> chcp 866 Active code page: 866 PS C:\Users\Алексей\ghc-8.4.2\bin> .\ghc-pkg.exe list C:\Users\Алексей\ghc-8.4.2\lib\package.conf.d Cabal-2.2.0.1 Win32-2.6.1.0 array-0.5.2.0 base-4.11.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.11.0 deepseq-1.4.3.0 directory-1.3.1.5 filepath-1.4.2 (ghc-8.4.2) ghc-boot-8.4.2 ghc-boot-th-8.4.2 ghc-compact-0.1.0.0 ghc-prim-0.5.2.0 ghci-8.4.2 haskeline-0.7.4.2 hpc-0.6.0.3 integer-gmp-1.0.2.0 mtl-2.2.2 parsec-3.1.13.0 pretty-1.1.3.6 process-1.6.3.0 rts-1.0 stm-2.4.5.0 template-haskell-2.13.0.0 text-1.2.3.0 time-1.8.0.2 transformers-0.5.5.0 xhtml-3000.2.2.1 PS C:\Users\Алексей\ghc-8.4.2\bin> }}} Curiously, setting {{{chcp 65001}}} when locale is already set to Russian through the control panel results in a powershell crash, but not when locale is English(United States). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 27 22:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Apr 2018 22:40:47 -0000 Subject: [GHC] #15083: cannot install GHC on CentOS In-Reply-To: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> References: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> Message-ID: <060.9644d06d11db61e1a0af4882580bf4ac@haskell.org> #15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: | -------------------------------------+------------------------------------- Comment (by kbrown): Update: when I set the resolver to use 7.10.2, I do not get this error. I cannot yet determine if GHC 8.02 causes this error as the installation has been taking extremely long - if I find out I can update this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 01:05:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 01:05:22 -0000 Subject: [GHC] #15096: GHC fails to execute gcc on Windows when unicode character is in the path Message-ID: <042.e5997dea2909a753cc3e4428c3168ba3@haskell.org> #15096: GHC fails to execute gcc on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: #15021 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens when the location of gcc is under a path with non-ASCII directory in it: {{{ PS C:\Users\日\stack-test> & 'C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.exe' -no- user-package-db .\Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) : error: Warning: Couldn't figure out C compiler information! Make sure you're using GNU gcc, or clang Unable to start C:\Users\?\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin/realgcc.exe (error code: 123) `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} Tested with ghc 8.0.2 on Windows Server 2016 (same setup as in #15021). This was discovered as part of the effort to make Haskell tooling work well for users with non-ASCII user names: https://github.com/commercialhaskell/stack/issues/3988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 01:06:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 01:06:20 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.8e360ac4346c962c35db9f97a78950c6@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * failure: None/Unknown => GHC doesn't work at all * related: #10762 => #10762, #15096 Comment: This was discovered as part of the effort to make Haskell tooling work well for users with non-ASCII user names: ​https://github.com/commercialhaskell/stack/issues/3988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 01:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 01:08:34 -0000 Subject: [GHC] #15096: GHC fails to execute gcc on Windows when unicode character is in the path In-Reply-To: <042.e5997dea2909a753cc3e4428c3168ba3@haskell.org> References: <042.e5997dea2909a753cc3e4428c3168ba3@haskell.org> Message-ID: <057.2f47803c16aa26254ff1fcba2e4f8c8c@haskell.org> #15096: GHC fails to execute gcc on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #15021 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nh2: Old description: > This happens when the location of gcc is under a path with non-ASCII > directory in it: > > {{{ > PS C:\Users\日\stack-test> & 'C:\Users\日 > \AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.exe' -no- > user-package-db .\Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > : error: > Warning: Couldn't figure out C compiler information! > Make sure you're using GNU gcc, or clang > Unable to start > C:\Users\?\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin/realgcc.exe > (error code: 123) > `gcc.exe' failed in phase `Assembler'. (Exit code: 1) > }}} > > Tested with ghc 8.0.2 on Windows Server 2016 (same setup as in #15021). > > This was discovered as part of the effort to make Haskell tooling work > well for users with non-ASCII user names: > https://github.com/commercialhaskell/stack/issues/3988 New description: This happens when the location of gcc is under a path with non-ASCII directory in it: {{{ PS C:\Users\日\stack-test> & 'C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.exe' -no- user-package-db .\Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) : error: Warning: Couldn't figure out C compiler information! Make sure you're using GNU gcc, or clang Unable to start C:\Users\?\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin/realgcc.exe (error code: 123) `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} Tested with ghc 8.0.2 on Windows Server 2016 with the system locale set to `English (US)` (same setup as in #15021, see there for how to set the locale). This was discovered as part of the effort to make Haskell tooling work well for users with non-ASCII user names: https://github.com/commercialhaskell/stack/issues/3988 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 05:56:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 05:56:30 -0000 Subject: [GHC] #15083: cannot install GHC on CentOS In-Reply-To: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> References: <045.7e67b77b591706785cdb1ff7a459166b@haskell.org> Message-ID: <060.d7a7fd346bac4fcb5f0715b8cb86a67c@haskell.org> #15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by kbrown): * status: new => closed * resolution: => fixed Comment: The problem seems to have been related to compilers on my end (though it is unclear which specific software was out of date), and they've now been fixed, allowing me to install GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 07:13:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 07:13:56 -0000 Subject: [GHC] #15097: Missing instance Applicative (K1 i c) Message-ID: <045.172e50b19d5c27f5f3069d16956d6aba@haskell.org> #15097: Missing instance Applicative (K1 i c) -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC.Generics has common instances for various haskell classes. It is missing the instance for Applicative (K1 i c) -- `K1 i` is morally like `Const` so it should have the same set of instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 07:49:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 07:49:26 -0000 Subject: [GHC] #15097: Missing instance Applicative (K1 i c) In-Reply-To: <045.172e50b19d5c27f5f3069d16956d6aba@haskell.org> References: <045.172e50b19d5c27f5f3069d16956d6aba@haskell.org> Message-ID: <060.a018cd192eb3caab5f80b220be302521@haskell.org> #15097: Missing instance Applicative (K1 i c) -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14849 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * related: => #14849 Comment: This seems to be fixed in #14849. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 10:00:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 10:00:13 -0000 Subject: [GHC] #15097: Missing instance Applicative (K1 i c) In-Reply-To: <045.172e50b19d5c27f5f3069d16956d6aba@haskell.org> References: <045.172e50b19d5c27f5f3069d16956d6aba@haskell.org> Message-ID: <060.7fc5a9f02733004f871e7bbff3d99c8e@haskell.org> #15097: Missing instance Applicative (K1 i c) -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14849 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 11:01:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 11:01:05 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.8322e53b67f7669d1226a3206c11e566@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonpj, bgamari (added) * priority: normal => highest Comment: Finally found the problem. In summary; in unarise we introduce `absentError` calls for unboxed sum slots that are not supposed to be used and `absentError` id (`aBSENT_ERROR_ID`) is marked as CAFFY. Now suppose we had a top-level definition that is not CAFFY but uses unboxed sums. `TidyPgm` thinks that it's not CAFFY. But in unarise we make it CAFFY. This causes mismatch between the CAF info recorded in the binder id for this top-level definition and the actual RHS. The code that generates closure layout doesn't add a static_link field, but the code that generates the info table generates a SRT and SRT bitmap. Some potential solutions: - Why is `absentError` marked as CAF? I think error ids are conservatively marked as `MayHaveCafRefs` but perhaps it's fine to not mark `absentError` as `MayHaveCafRefs`. (I implemented this and it fixed the bug) - Update CAFFY-ness of ids in unarise if we introduce `absentError` (haven't tried this yet) - Something else? Any ideas? Ping @simonpj @bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 11:19:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 11:19:07 -0000 Subject: [GHC] #15098: Missing instances for Down Message-ID: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> #15098: Missing instances for Down -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 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: -------------------------------------+------------------------------------- `Down` in `Data.Ord` is missing the instances for `Monad`, `MonadFix`, `MonadZip`, `Eq1`, `Ord1`, `Show1`, `Read1`, `Data`, `Generic`, `Generic1`, `Foldable`, `Traversable`. We added a bunch of common sense 'only one definition' instances over the last few GHC releases, but apparently we missed `Data.Ord.Down`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 11:47:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 11:47:35 -0000 Subject: [GHC] #15099: Missing instances for Data.Monoid.Alt Message-ID: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> #15099: Missing instances for Data.Monoid.Alt -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- We're missing `Foldable`/`Traversable` instances for `Data.Monoid.Alt`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 14:32:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 14:32:03 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.f5150e417bea9ea304eb76d7a7e99b55@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 bgamari): Good sleuthing! However, I'm not sure about marking `absentError` as non-CAFFY. Afterall, judging by its RHS it looks as though it may carry a reference to at least one CAF (namely `unpackCString# "Oops! Entered absent arg"#). Have you looked at the STG that is produced for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 14:55:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 14:55:46 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.911ba70a7c5deb23898af7c12a646882@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 osa1): > STG that is produced for this? Do you mean STG for `absentError` or the function with wrong CAFFY-ness information? I haven't checked `absentError` but this is the STG for the function with wrong CAFFYness information: {{{ lvl3_rctu :: forall s. Packed.Bytes.Parser.Maybe# (Packed.Bytes.Parser.Leftovers# s) -> GHC.Prim.State# s -> (# GHC.Prim.State# s, Packed.Bytes.Parser.Result# s GHC.Types.Word #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [us_gcwc us_gcwd us_gcwe us_gcwf us_gcwg void_0E] case us_gcwc of tag_gcwh { __DEFAULT -> (#,,,,,,#) [1# Control.Exception.Base.absentError Control.Exception.Base.absentError 0## 0## 1# Control.Exception.Base.absentError]; 2# -> case ># [us_gcwg 0#] of { __DEFAULT -> case Packed.Bytes.Parser.nextNonEmpty us_gcwe GHC.Prim.void# of { (#,,,,#) us_gcwi us_gcwj us_gcwk us_gcwl us_gcwm -> case us_gcwi of tag_gcwn { __DEFAULT -> (#,,,,,,#) [1# Control.Exception.Base.absentError Control.Exception.Base.absentError 0## 0## 1# Control.Exception.Base.absentError]; 2# -> case -# [us_gcwm 1#] of sat_scuk { __DEFAULT -> case +# [us_gcwl 1#] of sat_scuj { __DEFAULT -> (#,,,,,,#) [2# us_gcwj us_gcwk sat_scuj sat_scuk 2# a1_rcbR]; }; }; }; }; 1# -> case -# [us_gcwg 1#] of sat_scur { __DEFAULT -> case +# [us_gcwf 1#] of sat_scuq { __DEFAULT -> (#,,,,,,#) [2# us_gcwd us_gcwe sat_scuq sat_scur 2# a1_rcbR]; }; }; }; }; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 15:03:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 15:03:15 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.28a0ab5d98ac119b92aa5193501a6595@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 bgamari): The STG for `absentError`; we want to know specifically whether it is necessary to mark it as CAFFY. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 28 16:54:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Apr 2018 16:54:34 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.2c6ffebe57678c4575bb9105bdf4bff7@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 osa1): STG for `absentError`: {{{ lvl_r3wv :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] = "Oops! Entered absent arg "#; Control.Exception.Base.absentError :: forall a. GHC.Prim.Addr# -> a [GblId, Arity=1, Str=x, Unf=OtherCon []] = [] \r [s_s3BA] let { sat_s3BB [Occ=Once] :: [GHC.Types.Char] [LclId] = [s_s3BA] \u [] GHC.CString.unpackCStringUtf8# s_s3BA; } in case GHC.CString.unpackAppendCString# lvl_r3wv sat_s3BB of sat_s3BC { __DEFAULT -> GHC.Err.errorWithoutStackTrace sat_s3BC; }; }}} Apparently this is CAFFY (othewise we'd see `Caf=NoCafRefs`). I also realized that unarise uses `absentError` wrong: `absentError` expects an `Addr#` argument (for a string that represents the "absent" argument) but unarise just uses `absentError` without an argument. So there's also a type error. Applying `absentError` to an argument in unarise would mean let bindings (heap allocation) so perhaps we should use something else for unused pointer location in unboxed sums. (IIRC when we first used `absentError` it wasn't taking an argument) If the id we'll use instead of `absentError` is not CAFFY then this problem will disappear. However I wonder if we could somehow implement a check that ensures we won't make things more caffy after `TidyPgm` in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 15:14:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 15:14:02 -0000 Subject: [GHC] #10572: Type signatures are not implicitly quantified over TH type variables In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.65ddff13d65159dfb7ae7b14bf507036@haskell.org> #10572: Type signatures are not implicitly quantified over TH type variables -------------------------------------+------------------------------------- Reporter: spinda | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/th/T10572a, tests/th/T10572a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4641 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * testcase: => tests/th/T10572a, tests/th/T10572a * status: new => patch * differential: => Phab:D4641 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 16:40:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 16:40:18 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.140730bd70e17d6b68761d4e533013a1@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The testsuite driver indeed already has support for this. See 54d3a1fdeb7044a1d9bb025d4880d08c708b4cd0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 17:13:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 17:13:06 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.a9f8a4222593b1e4e16b2cc5446dae64@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jrp): * Attachment "testsuite_summary.2.txt" added. validate --slow result -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 18:41:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 18:41:31 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.1a96b015be1071b288a91ffe0c2ecb0c@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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 bgamari): Replying to [comment:19 osa1]: > STG for `absentError`: ... > > Apparently this is CAFFY (othewise we'd see `Caf=NoCafRefs`). > Right, that's what I suspected. > I also realized that unarise uses `absentError` wrong: `absentError` expects an `Addr#` argument (for a string that represents the "absent" argument) but unarise just uses `absentError` without an argument. So there's also a type error. > Yikes! It seems like this is one case that the old STG lint type-checker likely could have caught. Oh well. > Applying `absentError` to an argument in unarise would mean let bindings (heap allocation) so perhaps we should use something else for unused pointer location in unboxed sums. (IIRC when we first used `absentError` it wasn't taking an argument) > > If the id we'll use instead of `absentError` is not CAFFY then this problem will disappear. Yes, this seems like the shortest path to solving this. Introduce a variant of `absentError` that throws a less helpful error message but requires no allocation and isn't caffy. > However I wonder if we could somehow implement a check that ensures we won't make things more caffy after `TidyPgm` in the future. The whole interaction between CorePrep, CoreTidy, and caffyness is quite unfortunate. It would be better if CorePrep and CoreTidy were less coupled in this regard. I thought there was a ticket discussing this, but I'm having trouble finding it at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 18:44:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 18:44:34 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.970c97d42659790e5871e22f223f5026@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 18:54:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 18:54:50 -0000 Subject: [GHC] #15100: `ApplicativeDo` needlessly uses `join` too much Message-ID: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> #15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs foo = do A 1 B 2 C 3 return () }}} produces very different code than {{{#!hs foo = do A 1 B 2 C 3 }}} for no good reason. Currently we check to see if the last clause is a `return` or something else, and then bolt a `join` in if it isn't `return`. But this check is too conservative. If it isn't a `return` but doesn't reference any of the variables above, you can still desugar it with `(<*>)`. We found this during a twitch livestream in front of an audience of 127 people. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 18:57:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 18:57:37 -0000 Subject: [GHC] #15100: `ApplicativeDo` needlessly uses `join` too much In-Reply-To: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> References: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> Message-ID: <060.3053663acea9690940b49c373d1ce9c0@haskell.org> #15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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 adamse): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:26:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:26:55 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.f01afb0f71c4b2becd48e7c264f15e5a@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * cc: Phyx- (added) Comment: Strange that we don't see this on Linux i386. Any idea what might be going on here, Phyx? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:38:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:38:53 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.ff71c9fb85bf2ea35725d904e88913e1@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): I think this is a bug/misfeature in GNU as: https://sourceware.org/bugzilla/show_bug.cgi?id=23040 (apparently, "." is evaluated wrt. the destination of the .uleb128 directive, which is .note .GNU-stack) In any case, as a workaround, one can evaluate the expression before using it: {{{ uleb128_value = 1f-.-1 .uleb128 = uleb128_value ;instead of ; .uleb128 1f-.-1 }}} The name can be reused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:40:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:40:40 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.38361ea5ee630018239131127b209202@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): I mean `.uleb128 uleb128_value` (no equality sign), of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:42:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:42:54 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.63a1d60f5d21cdb9323e248b7e7432c2@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4642 Comment: See Phab:D4642 for a quick attempt at a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:43:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:43:06 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.d13a778c320506f41744667602bf1bee@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 20:44:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 20:44:05 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.39d68898c30884fe7c0bc9bc603a2c72@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): It's a problem with the library. `x86` doesn't have a `64 bit` (`DImode`) `divmod` instruction. So GCC emulates it using a compiler built-in `___divmoddi4`. Since the library uses this built-in it needs to link against `libgcc`. It's not a problem for x86 Linux because of `dynamic-way`. When the `so` is made GCC links in `libgcc` so the problem doesn't show. Using non- dynamic-way will have the same issue on Linux as well. The clock library needs to add `extra-libraries: gcc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 29 21:23:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Apr 2018 21:23:29 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.e497183742f9f7cd48a14c7cd4b0b823@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): > The name can be reused. While I think that this ''should'' be true, I'm actually not sure... I did a test with `.long`, but perhaps that was not adequate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 00:54:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 00:54:23 -0000 Subject: [GHC] #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches In-Reply-To: <049.d7a6f5ef2f062ac53f62143ee65e850a@haskell.org> References: <049.d7a6f5ef2f062ac53f62143ee65e850a@haskell.org> Message-ID: <064.2e93cee2ffff46302f3469375c64d845@haskell.org> #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This sounds reasonable to me. Of course, we will also want a way to prevent `-dsuppress-ticks` for tests that actually test ticks. Perhaps we actually want a flag to suppress source notes in particular. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 01:33:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 01:33:09 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.46f6057d4411602a84413c50cfac18c0@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lehins): The quickfix proposed is OK, but it't not enough, since the right way is to alos set the code page to 65001 on Windows so after the utf8 encoding is applied it not only doesn't error out but also actually prints out the correct characters. I was able to get this working to day, will try to add a fix tomorrow. Here is the quickfix proposed by @bgamari in action: {{{ PS C:\phab\ghc-pkg\.stack-work\install\b82bf5d2\bin> .\ghc-pkg.exe list --global-package-db C:\Users\Алексей\ghc-8.4.2\lib\package.conf.d C:\Users\╨É╨╗╨╡╨║╤ü╨╡╨╣\ghc-8.4.2\lib\package.conf.d Cabal-2.2.0.1 Win32-2.6.1.0 array-0.5.2.0 base-4.11.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.11.0 }}} Here is with a bit of extra (patch coming tomorrow, it's too late for me right now to submit anything) {{{ PS C:\phab\ghc-pkg\.stack-work\install\b82bf5d2\bin> .\ghc-pkg.exe list --global-package-db C:\Users\Алексей\ghc-8.4.2\lib\package.conf.d C:\Users\Алексей\ghc-8.4.2\lib\package.conf.d Cabal-2.2.0.1 Win32-2.6.1.0 array-0.5.2.0 base-4.11.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.11.0 deepseq-1.4.3.0 directory-1.3.1.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 02:44:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 02:44:29 -0000 Subject: [GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. In-Reply-To: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> References: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> Message-ID: <069.a219c9e6f4eeac9d13028a1388d066e5@haskell.org> #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Floating | IEEE754 trigonometric Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: I don't really understand how you get your calculation of `huge`. Shouldn't that be `1/sqrt epsilon` rather than `1/epsilon`? If so, the cut-offs come out quite different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 02:46:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 02:46:55 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.5060be0fa593ab0063897174cbef4b23@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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): I'm confused; `+RTS -hT` works for me under both GHC 8.4.2 and 8.2.2 and indeed produces a `.hp` file after the program finishes. Are you perhaps building with profiling enabled? Do note that `-hT` is only available when *not* built with profiling (although admittedly it's not clear to me why this must be the case). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 02:48:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 02:48:46 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.997bddc1ac30413165be13cfb140e7a4@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4643 Comment: I've added `-hT` to the RTS help message in Phab:D4643. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 02:50:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 02:50:50 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix In-Reply-To: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> References: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> Message-ID: <059.aeb63a9aaa22e6386ed4e5efbd04463a@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: hvr (added) Comment: CCing Herbert who ported this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 03:56:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 03:56:33 -0000 Subject: [GHC] #15100: `ApplicativeDo` needlessly uses `join` too much In-Reply-To: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> References: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> Message-ID: <060.c76734f4c4ec3a93d989718d6b9032b5@haskell.org> #15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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 dfeuer): This is all around `stmtTreeToStmts` in `compiler/rename/RnExpr`, and `needJoin` seems rather relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 04:02:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 04:02:36 -0000 Subject: [GHC] #15100: `ApplicativeDo` needlessly uses `join` too much In-Reply-To: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> References: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> Message-ID: <060.ed58afd8d5912865ee241e776ea67503@haskell.org> #15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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 dfeuer): * cc: dfeuer (added) Comment: Another thing that should work doesn't quite: {{{#!hs foo a b c = do a b res <- c return res }}} This is even more surprising, because it desugars without `join` (and without `>>=`), but with `>>`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 04:18:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 04:18:05 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.6641480f4f0c2d506b0b116fa940d288@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Indeed Ben, I had profiling enabled (it's in the profiling section of the docs, after all!) A note in the help message is good, but the help message and docs need to be updated to indicate that profiling must be *off* for the option to be enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 07:29:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 07:29:17 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.0f137535bfd91dc9ff9ae741db69a050@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I've been doing some work on this in between other stuff, but haven't gotten very far yet. I have a `MCoercion` type in place (which is trivial), and my first approach was to just naively replace all `Maybe Coercion`s with `MCoercion` and then follow the compiler errors. However, this doesn't work out all that well, because some of those `Maybe`s are actually morally justified as such (i.e., `Nothing` does not not mean "this is a Refl coercion", but it actually means "nothing found" / "failure"). I was going to go through the code and look at all occurrences individually, but haven't gotten around to this yet. If someone wants to take this off me, and do the work for free, I say go ahead, I'm not emotionally invested in this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 07:46:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 07:46:31 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.871839034715b25cf165c295ed3bd966@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This also happens when booting GHC with GHC 8.4.2 on Ubuntu 18.04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 07:58:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 07:58:02 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.685a04e8edfead0f9cbee49ad5fb3b81@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: 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 was easy to integrate but the XML was malformed somehow. {{{ ParseError at [row,col]:[1,316] Message: The value of attribute "type" associated with an element type "failure" must not contain the '<' character. }}} https://circleci.com/gh/tweag/ghc/904#tests/containers/0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 08:03:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 08:03:32 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib Message-ID: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The nofib suite looks for gcc under $tooldir which doesn't seem to be expanded/set. {{{ > ~/ghc_head/nofib/shootout/fasta $ make boot $tooldir/mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /mingw/bin/gcc.exe: No such file or directory make: *** [Makefile:22: fasta-c] Error 127 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 08:32:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 08:32:15 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.c24b6b01279541618fe8b2aec0061e08@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: 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): In particular, the XML produced doesn't look like it follows the schema. https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_junit.html There appear to be a number of missing fields that are required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 08:49:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 08:49:30 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.09fe26b8759806efaae321442d6a1686@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | 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 AndreasK): Also fails when using ghc-8.2.1 {{{ $ make boot HC=ghc $topdir/../mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /../mingw/bin/gcc.exe: No such file or directory make: *** [Makefile:22: fasta-c] Error 127 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 09:35:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 09:35:29 -0000 Subject: [GHC] #15100: `ApplicativeDo` needlessly uses `join` too much In-Reply-To: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> References: <045.69cefb5ac68338b5b0272026f5e7f8b9@haskell.org> Message-ID: <060.5de5229b81ab30b81748c29b4c33cf3d@haskell.org> #15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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 simonpj): * cc: simonmar (added) Comment: cc'ing Simon Marlow, the king of `ApplicativeDo`. Whatever emerges, I'd love to see it expressed in the language of the paper. I found the division in the paper (into a dependency analysis followed by desugaring) to be very helpful. If we could have a typeset appendix that gives the ''actual'' rules followed by GHC (including improvements described above) that would be incredibly helpful. Both for understanding the code, and for helping others who implement `ApplicativeDo` in their compilers. We can easily make the paper source code available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 09:41:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 09:41:23 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.8114b5b5e3f516f427ad343df60b46fb@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: I've been recently reading the relevant code, and I think this is indeed a bug. Basically we raise an async `BlockedIndefinitelyOnMVar` when a thread is not reachable and blocked in an MVar operation. Reachability in this context means: - If a thread has work to do it's reachable (because it's in run queue of one of the capabilities) - If a thread is blocked in an MVar it's reachable iff the MVar is reachable Now suppose that thread_1 is blocked on mvar_1 and has a reference to mvar_2, and thread_2 is blocked on mvar_2, and both MVars become unreachable after a GC. This makes both thread_1 and thread_2 unreachable and we add them to the "thrads to resurrect" list. By the time we resurrect thread_1, mvar_2 becomes reachable, which makes thread_2 reachable as well. But we already added thread_2 to the "threads to resurrect" list so we raise an exception in thread_2 as well. I think this is basically what's happening in this ticket. Why adding a delay fixes this? Because by the time the main thread is paused with the delay it's in the run queue of the capability because it has more work to do. So the delay makes the main thread reachable for a few more GC cycles, and `BlockedIndefinitelyOnMVar` is only raised on resurrected (unreachable) threads. I think fixing this may be easy; instead of resurrecting all unreachable threads at once, we resurrect one from the list, then continue with the scavenge loop. I'll try this once my tree builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 09:48:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 09:48:00 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.d31cf48bfccb5e314714981eeabf05c9@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #10793 Comment: #10793 is basically the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 09:48:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 09:48:14 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.a574ff184623a2d6002475159405745f@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) * related: => #10241 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 09:52:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 09:52:01 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.8e6d7f606685e8749f6e904fc41886d6@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 10:10:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 10:10:21 -0000 Subject: [GHC] #15102: GHC panic when compiling gi-pango-1.0.15 Message-ID: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> #15102: GHC panic when compiling gi-pango-1.0.15 -------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- I got the following error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing Layout which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find Layout in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface }}} A self-contained Stack project that demonstrates the problem is attached. I'm using Stack Version 1.6.3 x86_64 hpack-0.20.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 10:10:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 10:10:54 -0000 Subject: [GHC] #15102: GHC panic when compiling gi-pango-1.0.15 In-Reply-To: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> References: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> Message-ID: <065.7a1e3ee826988f4022e9581d5c2c12ca@haskell.org> #15102: GHC panic when compiling gi-pango-1.0.15 -------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 PaulJohnson): * Attachment "ghc-bug.tgz" added. Stack project that demonstrates the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 10:34:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 10:34:51 -0000 Subject: [GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. In-Reply-To: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> References: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> Message-ID: <069.5cd727a23d19f26b8fe886e941aacd46@haskell.org> #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Floating | IEEE754 trigonometric 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 leftaroundabout): Yes, the cut-offs come out different, but it doesn't really matter: `sqrt (1 + x*x)` is still stable and accurate for a long way even when `x` is so big that `1 + x*x == x*x`. So, whereas it's important that `huge` should not be ''smaller'' than `1/sqrt epsilon ≈ 6.7e7`, it ''can'' actually be much bigger: `1e100` would also work in case of `Double`. Therefore, `1/epsilon ≈ 4.5e15` is a safe compromise that's presumably less likely to give new surprising corner-cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 10:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 10:39:47 -0000 Subject: [GHC] #15102: GHC panic when compiling gi-pango-1.0.15 In-Reply-To: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> References: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> Message-ID: <065.c83a61d53e87984aa6068cba1cd731a9@haskell.org> #15102: GHC panic when compiling gi-pango-1.0.15 -------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 PaulJohnson): I now see that this is a dupe of #14382. Also I should have remembered that this is flagged up as a known issue in https://github.com/haskell-gi /haskell-gi. So you probably want to close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 11:34:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 11:34:58 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.00e5540dbb95c3941a797021a61a75bf@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: 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): Here is the generated XML. https://911-16347359-gh.circle-artifacts.com/0/home/ghc/project/test- results/junit.xml I think I can see where the problem is coming from.. Will submit a patch later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:12:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:12:58 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.8539c8df03e6840187bada698b1d0c53@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Replying to [comment:10 simonpj]: > 1. Represent `imp_finsts` as a `ModuleSet` > There's a helpful `Note [Combine ImportAvails]` in `RnNames` which explains why a set is a bit awkward. I think a Set can work out if you go all the way, also changing `dep_finst`. > My instinct is to try a `Bag` (so that `plusAvails` can use `unionBags` which is always fast), and move the removing-duplicates work to the consumer. Then we could simplify the code in `RnNames`. > > I think there are two consumers of `imp_finsts`: > > * `tcExtendLocalFamInstEnv` loads up dependent modules. So we'd need eliminate duplicates, but determinacy is not an issue > * `DsUsage.mkDependencies` which already does a sort, so removing dups at the same time should surely not be hard. I think this can work, but we'd have to remove dups from `A`'s `imp_finsts` before computing `imp_finsts` for `B` if `B` imports `A`. Otherwise for bigger module hierarchies a lot of duplicates will accumulate. I believe the existing tests already measure this, so it should be possible to compare the approaches quantitatively. It's unfortunate that we must keep and store a set of transitive dependencies for every module. The size just grows with the size of the codebase. I think for `imp_finsts` and `dep_finsts` the only reason we do that is so that we can do type family instance checks and avoid redoing some checks. See `Note [Checking family instance optimization]`. There's an assumption somewhere in there that having the transitive set in hand lets us load less interfaces. I'm skeptical of how it works out in practice. Perhaps we could avoid explicitly storing the whole transitive closure if when checking type family consistency we did a traversal with pruning instead. I haven't thought it through fully, so take this with a grain of salt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:20:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:20:08 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.97395b0818aa262f8c6b3c294ba84ebb@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > I think fixing this may be easy; instead of resurrecting all unreachable threads at once, we resurrect one from the list, then continue with the scavenge loop. I'll try this once my tree builds. This fix works: Phab:D4644. I'll now try to validate to see if it breaks anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:25:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:25:23 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks Message-ID: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4597 | Wiki Page: -------------------------------------+------------------------------------- == Use toBlockList instead of revPostorder. Block elimination works on a given Cmm graph by: * Getting a list of blocks. * Looking for duplicates in these blocks. * Removing all but one instance of duplicates. There are two (reasonable) ways to get the list of blocks. * The fast way: `toBlockList`: This just flattens the underlying map into a list. * The convenient way: `revPostorder`: Start at the entry label, scan for reachable blocks and return only these. This has the advantage of removing all dead code. If there is dead code the later is better. Work done on unreachable blocks is clearly wasted work. However by the point we run the common block elimination pass the input graph already had all dead code removed. This is done during control flow optimization in CmmContFlowOpt which is our first Cmm pass. This means common block elimination is free to use toBlockList because revPostorder would return the same blocks. (Although in a different order). == Change the triemap used for grouping by a label list from `(TM.ListMap UniqDFM)` to `ListMap (GenMap IntMap)`. * Using GenMap offers leaf compression. Which is a trie optimization described by the Note [Compressed TrieMap] in CoreSyn/TrieMap.hs * Using a IntMap removes the overhead associated with UniqDFM. The reasoning why this is deterministic after the change: * IntMap is deterministic given the same keys. * Labels have a Int representation, so for the same Labels we get the same keys, hence the same result for each run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:25:43 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.90c3ff598ec5aed5e2a4e2e21c45b460@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4597 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:26:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:26:08 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.250e9a423882a52b2a52cc5ea5f831d6@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4597 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:47:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:47:26 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.aa0e1d2bedfe33123b02f43398489e18@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:55:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:55:28 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.ee298ee2606300a054edc011b71342cd@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think this can work, but we'd have to remove dups from A's imp_finsts before computing imp_finsts for B if B imports A. Otherwise for bigger module hierarchies a lot of duplicates will accumulate. Yes, the idea is to allow dups to accumulate (which happens for free, just by `unionBags`) and then when ''consuming'' the bag simply avoid doing things twice. I think that's good, because generally we accumulate the `imp_fints` and then remove dups, sort, etc to make `dep_finists` for this module. But this approach does depend on the "accumulate and consume once" pattern. > Perhaps we could avoid explicitly storing the whole transitive closure if when checking type family consistency we did a traversal with pruning instead Maybe so, but I'm not certain. For sure you'd want to know whether a module had family instances either in itself or in its transitive imports. Let's call that the "finst flag" Then, to look for imported instances, you could say * For each imported module M, if its finst-flag is off, ignore M. * Otherwise, check for family instances in M, and then * Consider each direct import of M That'd require you to traverse a path of .hi files to get to the one with the family instances in it. (Currently we can jump direct to the latter.) But perhaps that's fine. Looks like a good thing to explore. We could do the same for orphan-instance modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 12:58:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 12:58:17 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.622fc0740e05aeb0939f96a7e824c9cb@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS. One bad case might be this: {{{ import A import B }}} where * A imports A1 which imports A2 .. which import A20, which imports F. * B imports B1 which imports B2 .. which import B20, which imports F. }}} and F has the family instances. I may have to walk down A.hi, A1.hi... to get to F. But it's painful to walk down B1, B2... etc as well. I wonder about having a Bloom filter, which might compactly summarise the set of family-instance modules below M? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:03:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:03:36 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.e7d6014834344cdf4730f4fca289ea28@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: 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): See https://phabricator.haskell.org/D4645 and https://phabricator.haskell.org/D4646 and for an example of the output - https://circleci.com/gh/tweag/ghc/920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:17:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:17:47 -0000 Subject: [GHC] #15104: Update JMP_TBL targets during shortcutting for x86 codegen. Message-ID: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> #15104: Update JMP_TBL targets during shortcutting for x86 codegen. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4595 | Wiki Page: -------------------------------------+------------------------------------- Jump tables are generated from Cmm Code in a few steps: 1. We start with a CmmSwitch at the end of the Cmm pipeline which gets turned into a JMP_TBL instruction. 2. During native codegen we generate static jump tables from JMP_TBL. (generateJumpTables) 3. We shortcut jump targets, for jump tables by updating the static tables. (shortcutBranches). This might update the jump targets with calculated address not represented by a label. After the third step the targets in the JMP_TBL instruction (which are the original labels) and in the static data can be out of sync. Phab:D4566 went part of the way, updating labels in JMP_TBL. However without tables next to code labels can be updated to non-label jump destinations which I did not consider at the time. Phab:D4595 is intended to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:22:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:22:54 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.78e233fd51f2130b81419fc1e07347bc@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ulysses4ever Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4503 Wiki Page: | -------------------------------------+------------------------------------- Description changed by ulysses4ever: Old description: > I noticed that the simplifier module depends on all of the type checker, > and HsSyn stuff, and renamer stuff, which I found strange. > > After a little investigation, it seems that the simplifier depends on > CoreMonad, and that pulls some very few type-checker related things: > > 1. > {{{ > import TcRnMonad ( initTcForLookup ) > import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) > }}} > for > {{{ > thNameToGhcName :: TH.Name -> CoreM (Maybe Name) > thNameToGhcName th_name = do > hsc_env <- getHscEnv > liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) > }}} > which is not even used in GHC, but only in GHC Plugins, so this could > probably be moved to a separate module pulled in by GhcPlugins.hs > > 2. > {{{ > import TcEnv ( lookupGlobal ) > }}} > for > {{{ > instance MonadThings CoreM where > lookupThing name = do { hsc_env <- getHscEnv > ; liftIO $ lookupGlobal hsc_env name } > }}} > This might be a bit harder to disentangle. But if successful, it > would > probably make building GHC in parallel quite a bit faster. And it > just > seems strange to me that the Core-to-Core code should depend on the > type checker… > > Simon says: > > > Both of these code paths go through initTcForLookup which is massive > overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly > a ToDo here to strip off the redundant stuff and do a minimal lookup. > > I am optimistically marking this as `newcomer` because it is a > refactoring task, and a good way of learning a bit about various pieces, > with a reasonably clear notion of “success”. New description: I noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange. After a little investigation, it seems that the simplifier depends on CoreMonad, and that pulls some very few type-checker related things: 1. {{{ import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) }}} for {{{ thNameToGhcName :: TH.Name -> CoreM (Maybe Name) thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} which is not even used in GHC, but only in GHC Plugins, so this could probably be moved to a separate module pulled in by GhcPlugins.hs 2. {{{ import TcEnv ( lookupGlobal ) }}} for {{{ instance MonadThings CoreM where lookupThing name = do { hsc_env <- getHscEnv ; liftIO $ lookupGlobal hsc_env name } }}} This might be a bit harder to disentangle. But if successful, it would probably make building GHC in parallel quite a bit faster. And it just seems strange to me that the Core-to-Core code should depend on the type checker… Simon says: > Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”. ---- **UPDATE** (April 2018, Phab:4503): both points described above are addressed to the extent when in order to close the ticket we need to do mere code movement. Namely. 1. `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. 2. `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point in the future in order to close the ticket. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:25:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:25:33 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.0519a9eb55470f4d9f2f952168832e10@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ulysses4ever Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4503 Wiki Page: | -------------------------------------+------------------------------------- Description changed by ulysses4ever: Old description: > I noticed that the simplifier module depends on all of the type checker, > and HsSyn stuff, and renamer stuff, which I found strange. > > After a little investigation, it seems that the simplifier depends on > CoreMonad, and that pulls some very few type-checker related things: > > 1. > {{{ > import TcRnMonad ( initTcForLookup ) > import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) > }}} > for > {{{ > thNameToGhcName :: TH.Name -> CoreM (Maybe Name) > thNameToGhcName th_name = do > hsc_env <- getHscEnv > liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) > }}} > which is not even used in GHC, but only in GHC Plugins, so this could > probably be moved to a separate module pulled in by GhcPlugins.hs > > 2. > {{{ > import TcEnv ( lookupGlobal ) > }}} > for > {{{ > instance MonadThings CoreM where > lookupThing name = do { hsc_env <- getHscEnv > ; liftIO $ lookupGlobal hsc_env name } > }}} > This might be a bit harder to disentangle. But if successful, it > would > probably make building GHC in parallel quite a bit faster. And it > just > seems strange to me that the Core-to-Core code should depend on the > type checker… > > Simon says: > > > Both of these code paths go through initTcForLookup which is massive > overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly > a ToDo here to strip off the redundant stuff and do a minimal lookup. > > I am optimistically marking this as `newcomer` because it is a > refactoring task, and a good way of learning a bit about various pieces, > with a reasonably clear notion of “success”. > > ---- > > **UPDATE** (April 2018, Phab:4503): both points described above are > addressed to the extent when in order to close the ticket we need to do > mere code movement. Namely. > > 1. `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely. Its > client, though, `thNameToGhcName`, is better to be moved in the future > also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. > Joachim suggested “any module reexported by GhcPlugins (or maybe even > that module itself)”. > > 2. `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to > the typechecker monad, but still resides in `TcEnv.hs` — it should be > moved out of Tc-land at some point in the future in order to close the > ticket. New description: I noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange. After a little investigation, it seems that the simplifier depends on CoreMonad, and that pulls some very few type-checker related things: 1. {{{ import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) }}} for {{{ thNameToGhcName :: TH.Name -> CoreM (Maybe Name) thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} which is not even used in GHC, but only in GHC Plugins, so this could probably be moved to a separate module pulled in by GhcPlugins.hs 2. {{{ import TcEnv ( lookupGlobal ) }}} for {{{ instance MonadThings CoreM where lookupThing name = do { hsc_env <- getHscEnv ; liftIO $ lookupGlobal hsc_env name } }}} This might be a bit harder to disentangle. But if successful, it would probably make building GHC in parallel quite a bit faster. And it just seems strange to me that the Core-to-Core code should depend on the type checker… Simon says: > Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”. ---- **UPDATE** (April 2018, Phab:4503): both points described above are addressed to the extent when in order to close the ticket we need to do mere code movement. Namely. 1. `lookupThName_maybe` and `initTcForLookup` are eliminated from `CoreMonad.hs` completely. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. 2. `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point in the future in order to close the ticket. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:34:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:34:19 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.245cca4de090fc355446fd97a8c50908@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Phab:D4644 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4644 Comment: Phab:D4644 passes validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 13:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 13:58:26 -0000 Subject: [GHC] #15104: Update JMP_TBL targets during shortcutting for x86 codegen. In-Reply-To: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> References: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> Message-ID: <062.2cc783cb4d3c663d3fe3866ff79b0891@haskell.org> #15104: Update JMP_TBL targets during shortcutting for x86 codegen. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.5 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): Phab:D4595 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:00:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:00:07 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.979f68c07a3e6bc80c2cfe77253cacb2@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:3 simonpj]: Is this tag accurate? After all it doesn't change the code being generated. It's strictly a optimization for making GHC faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:12:14 -0000 Subject: [GHC] #11953: Export Word32#, Word64# on all architectures In-Reply-To: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> References: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> Message-ID: <061.a89879945e4bedfe673c22baa50b1278@haskell.org> #11953: Export Word32#, Word64# on all architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): @michalt whats the current state of play on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:20:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:20:08 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH Message-ID: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------------+---------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199). I've attached a minimal program that uses the GHC API and exhibits the same problem. {{{ $ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs [1 of 1] Compiling Main ( Prog.hs, Prog.o ) Linking Prog ... $ ./Prog Main-no-TH.hs -package template-haskell $ ./Prog Main-TH.hs -package template-haskell Prog: lookupSymbol failed in relocateSection (RELOC_GOT) /usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands' Prog: Prog: unable to load package `integer-gmp-1.0.2.0' }}} In case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:20:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:20:51 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.f951fef53c19fd7a788fa14b3e8d5536@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: 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 harpocrates): * Attachment "Main-no-TH.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:21:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:21:20 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.a1d6f42bc5c403eafcd9df596e4f950a@haskell.org> #9173: Better type 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 goldfire): I think the time is ripe for this ticket, and it shouldn't be hard. Here are the pieces: 1. Update `TcErrors.mkExpectedActualMsg` to print out the `uo_thing` field of the `TypeEqOrigin` passed in. For example, if we're reporting an actual of `Maybe Int` and an expected of `Bool`, then `uo_thing` might hold `Just 5`. This step can likely be done by changing `msg1` of `mkExpectedActualMsg`. 2. Rip out the special treatment of kinds in `mkExpectedActualMsg`. Other than swapping out the word "kind" for "type", kinds and types should be treated the same. This special treatment is currently there solely to match pre-8.0 behavior. Doing this step should improve the error messages worsened by #14066 and fix, e.g., #14887. Concretely, this step is essentially to remove `msg5` from `mkExpectedActualMsg`. Those two steps, by themselves, would nail this ticket. But Simon and I think we can do better. Currently, the `uo_thing` of a `TypeEqOrigin` tracks the term (or type, during kind-checking) that has the "actual" type. (It's the `Just 5` mentioned in step 1.) However, we can also track the aspect of the context that leads us to expect the "expected" type. For example, this string could be something like "required as the condition of an `if`" or "of the second argument of `($)`" or "of the type used in a type signature". Here are example error messages: Code: `if 'x' then foo else bar` {{{ Type mismatch: `Char' /= `Bool' Actual: `Char' is the type of `'x'' Expected: `Bool` is the type required as the condition of an `if' }}} Code: `not $ 'x'` {{{ Type mismatch: `Char' /= `Bool' Actual: `Char` is the type of `'x'' Expected: `Bool` is the type of the second argument of ($) }}} Code: `foo :: Maybe` {{{ Kind mismatch: `* -> *' /= `*' Actual: `* -> *' is the kind of `Maybe' Expected: `*` is the kind of the type used in a type signature }}} Aren't these just lovely? To do this: 3. Add an `SDoc` field to the `Check` constructor of an `ExpType` (in `TcType`). Then, in every `mkCheckExpType`, supply an appropriate message. Ideally, this message will not mention any types, because there will be no chance to zonk them later. 4. Add a new field `uo_context` to `TypeEqOrigin` (of type `Maybe SDoc`) that will get the doc from the `Check`. This seems like it will happen in `TcUnify.tcSubTypeDS_NC_O`, but perhaps in other places, too. It's worth checking every place we make a `TypeEqOrigin`. 5. Teach `TcErrors.mkExpectedActualMsg` to use this new info. We could do steps 1-2 separately from 3-5, but given the very large number of error messages one would have to sweep through to do so, it seems best to common these changes up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:21:29 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.ec932feb93091f6e2da14bf07ad13c43@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: 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 harpocrates): * Attachment "Main-TH.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:21:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:21:59 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.b63ffe2c9333915ce50a89e97d3f058c@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: 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 harpocrates): * Attachment "Prog.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:29:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:29:08 -0000 Subject: [GHC] #15106: Explore using pure unifier instead of monadic one Message-ID: <047.5d1c770722f2569729e87a4d180573d6@haskell.org> #15106: Explore using pure unifier instead of monadic one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC contains no fewer than three unifiers! This ticket is about removing one of them. Here are the three: 1. The eager monadic unifier, implemented in `TcUnify`, takes the first stab at unification during type inference. If it runs into trouble, it defers the equality to the solver. It returns a coercion. 2. The pure unifier works to sort out type family reductions, instance selection, and rule matching. It's implemented in `Unify`. This unifier returns, upon success, a substitution. 3. The solver contains a unification-like algorithm in `TcCanonical` that decomposes equalities en route to solving them. Simon and I hit upon a radical idea this morning: what if eager unification simply called the pure unifier? The pure unifier can also take a set (or description) of variables that can be in the domain of the returned substitution. In the case of the eager unifier, this domain would be the metavariables. The pure unifier would, if successful, return a substitution from metavariables to types, and the monadic code would simply use this substitution to fill in the types. It's not yet clear what the implications of this change would be on performance, but it seems like an interesting idea to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 14:54:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 14:54:39 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.6a5551ac7ce781b14e02e67eb1579633@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Replying to [comment:14 simonpj]: > PS. One bad case might be this: > {{{ > import A > import B > }}} > where > * A imports A1 which imports A2 .. which import A20, which imports F. > * B imports B1 which imports B2 .. which import B20, which imports F. > }}} > and F has the family instances. I may have to walk down A.hi, A1.hi... to get to F. But it's painful to walk down B1, B2... etc as well. I think you could mitigate this particular bad case if you did "path compression", that is instead of keeping the `finst-flag`, you remembered the first "interesting" module - a module that either defines it's own family instances or imports two modules with different "interesting" modules. Or framing it in terms of the current logic, a module is "interesting" if the `imp_finst` of a module is a strict superset of `imp_finst` of all the imports. A harder bad case would be a balanced binary tree of imports where only the leaves define type family instances. If you're compiling the root you're forced to load the interfaces of all the modules. It's `n` interface file loads instead of the minimal `n/2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 15:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 15:08:18 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.47d4f7f9d0c4997ceba05339e0c99b32@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: 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 harpocrates): The problem doesn't manifest itself with an inplace GHC. {{{ $ diff Prog.hs InplaceProg.hs 4d3 < import qualified GHC.Paths as GhcPaths 9c8 < libDir <- pure GhcPaths.libdir --- > let libDir = "./inplace/lib" }}} Then, {{{ $ ./inplace/bin/ghc-stage2 -package ghc -package containers InplaceProg.hs [1 of 1] Compiling Main ( InplaceProg.hs, InplaceProg.o ) Linking InplaceProg ... $ ./InplaceProg Main-no-TH.hs -package template-haskell $ ./InplaceProg Main-TH.hs -package template-haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 15:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 15:14:15 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.1b6afdcfae9f229b3056ec140fe2cbf8@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #9718 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 15:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 15:15:50 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.d462434649ed9acb751a21966b8f312a@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 15:38:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 15:38:04 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.dfe29f63eecd8d8f585b650306f48b8f@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556, Wiki Page: | Phab:D4617 -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Jaffacake (removed) * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 15:46:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 15:46:56 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.c2792f6aabc6b58d2758a912320647b2@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Hi there. This is Ningning. I am one of the students of GSoC this year under advised by Richard. Find more information about [https://summerofcode.withgoogle.com/projects/#5851493949767680/ my proposal]. Thanks to tdammers, I am taking this ticket as my warm-up exercise :). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 16:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 16:28:04 -0000 Subject: [GHC] #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled In-Reply-To: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> References: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> Message-ID: <061.4b55d2998105bde24db1cc8e11115e11@haskell.org> #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled -------------------------------------+------------------------------------- Reporter: rotaerk | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4648 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4648 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 16:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 16:37:13 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.c0bebe5c8e59773298174cdc63b4f0cf@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | 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 alpmestan): * cc: alpmestan (added) * owner: (none) => alpmestan Comment: On IRC, Andreas pointed me to the `--info` output for both 8.2.1 and HEAD. See [http://lpaste.net/365396 this lpaste]. The problem is that nofib uses the output of `--info` to set `CC` (and surely some other env vars), and we do not expand `$tooldir` in the `--info` output yet. We need to add a settings field `tooldir :: Maybe FilePath` and use it in `compilerInfo` to expand all occurences of `$tooldir`, using `expandToolDir`. The result should be a patch similar to [https://phabricator.haskell.org/D4222 this one], only for tooldir instead of topdir. I'll do my best to submit a diff that implements this sometimes this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 20:49:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 20:49:43 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.997771b93a7de1dc2057cfacb8dbfee9@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, but it makes it appear on [wiki:Commentary/Compiler/CodeGen this page] which collects backend tickets generally. I'd be entirely happy with a finer-grain categorisation, if you would like to propose one, but I'm finding these topic pages quite helpful. Here's [wiki:Status/SLPJ- Tickets my list of topics]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 20:56:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 20:56:49 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.e85f38a1382dd9a37f36d2005a7f12ab@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think you could mitigate this particular bad case if you did "path compression", that is instead of keeping the finst-flag, you remembered the first "interesting" module - a module that either defines it's own family instances or imports two modules with different "interesting" modules Interesting idea. Do you feel inclined to work on it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 21:00:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 21:00:55 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.d91474af86301574e19212dcb59558ea@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Phab:D4626 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sandy Maguire (isovector) has authored * [A GHC proposal] describing the proposed change * [Phab:D4626] as a draft implementation patch Next steps: community feedback on the above proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 21:47:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 21:47:20 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.7df14e460cbcc5a07df504d6571f83f0@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 mpickering): I think this is solved by DerivingVia? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:02:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:02:54 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.7ca914492702df0468479c8785baa2d8@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 simonpj): #15038 is a bug that would not have arisen if we'd implemented this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:03:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:03:47 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.aa19fbcac48d5e1d74fe9ac6f9f9b7a6@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I also realized that unarise uses absentError wrong: absentError expects an Addr# argument (for a string that represents the "absent" argument) but unarise just uses absentError without an argument. So there's also a type error. That is pretty terrible. I suggest making a separate ticket and fixing it asap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:05:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:05:05 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.0559eefacaa92f51042b57b11430ab15@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The whole interaction between CorePrep, CoreTidy, and caffyness is quite unfortunate. It would be better if CorePrep and CoreTidy were less coupled in this regard. I thought there was a ticket discussing this, but I'm having trouble finding it at the moment. It's #9718, and I wonder if we should devote some effort to nailing it? It's not that hard, and the status quo is a continuing source of fragility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:05:23 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.631ba0dd32f6f7a8b20a9bae8d8a6814@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: good sleuthing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:09:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:09:14 -0000 Subject: [GHC] #15106: Explore using pure unifier instead of monadic one In-Reply-To: <047.5d1c770722f2569729e87a4d180573d6@haskell.org> References: <047.5d1c770722f2569729e87a4d180573d6@haskell.org> Message-ID: <062.d227ca1e0ed700e311f0f9e68bf5f292@haskell.org> #15106: Explore using pure unifier instead of monadic one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Simon and I hit upon a radical idea this morning: what if eager unification simply called the pure unifier? One problem with this: we'd need to zonk, and then call the pure unifier; two passes, which seems sub-optimal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:36:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:36:19 -0000 Subject: [GHC] #15107: Testsuite failures on Windows Message-ID: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- For some time now there have been quite a few testsuite failures on Windows, but that number seems to have increaded recently. Here are the failures from {{{ sh validate --fast }}} with today's HEAD {{{ SUMMARY for test run started at Mon Apr 30 16:41:18 2018 GMTST 5:46:04 spent to go through 6321 total tests, which gave rise to 18197 test cases, of which 11980 were skipped 46 had missing libraries 5963 expected passes 171 expected failures 6 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 6 unexpected stat failures Unexpected failures: backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad exit code] (normal) backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad exit code] (normal) cabal/ghcpkg05.run ghcpkg05 [bad stderr] (normal) ghci/linking/ghcilink001.run ghcilink001 [bad exit code] (normal) ghci/linking/ghcilink004.run ghcilink004 [bad exit code] (normal) ghci/linking/dyn/big-obj.run big-obj [bad exit code] (normal) ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci) ghci/scripts/T9293.run T9293 [bad stdout] (ghci) ghci.debugger/scripts/break006.run break006 [bad stdout] (ghci) ghci.debugger/scripts/hist001.run hist001 [bad stdout] (ghci) ghci.debugger/scripts/hist002.run hist002 [bad stdout] (ghci) perf/compiler/T14697.run T14697 [[Errno 2] No such file or directory: '/c/Users/simonpj/AppData/Local/Temp/ghctest- 4kcp39ag/test spaces/./perf/compiler/T14697.run/T14697.comp.stats'] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) rts/T11788.run T11788 [bad exit code] (normal) rts/T14695.run T14695 [bad stderr] (normal) rts/T11223/T11223_simple_link.run T11223_simple_link [bad exit code] (normal) rts/T11223/T11223_simple_link_lib.run T11223_simple_link_lib [bad exit code] (normal) rts/T11223/T11223_simple_duplicate_lib.run T11223_simple_duplicate_lib [bad exit code] (normal) rts/T11223/T11223_simple_unused_duplicate_lib.run T11223_simple_unused_duplicate_lib [bad exit code] (normal) rts/T11223/T11223_link_order_a_b_succeed.run T11223_link_order_a_b_succeed [bad exit code] (normal) rts/T11223/T11223_link_order_b_a_succeed.run T11223_link_order_b_a_succeed [bad exit code] (normal) rts/T11223/T11223_link_order_a_b_2_fail.run T11223_link_order_a_b_2_fail [bad exit code] (normal) rts/T11223/T11223_link_order_b_a_2_succeed.run T11223_link_order_b_a_2_succeed [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) /../libraries/base/tests/tempfiles.run tempfiles [bad stdout] (normal) /../libraries/process/tests/T9775/T9775_fail.run T9775_fail [bad exit code] (normal) /../libraries/process/tests/T9775/T9775_good.run T9775_good [bad exit code] (normal) Unexpected stat failures: perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T14052.run T14052 [stat not good enough] (ghci) perf/should_run/T14936.run T14936 [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) safeHaskell/check/pkg01/ImpSafeOnly08.run ImpSafeOnly08 [runTest] (Unhandled exception during cleanup: Unable to remove folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-4kcp39ag/test spaces/./safeHaskell/check/pkg01/ImpSafeOnly08.run': [Errno 13] Permission denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-4kcp39ag/test spaces/./safeHaskell/check/pkg01/ImpSafeOnly08.run/pdb.ImpSafeOnly08/install/x86_64 -windows-ghc-8.5.20180420/safePkg01-1.0-LQOvw3iv9WM6fIcv695PaM' Unable to start current test.) ../../libraries/process/tests/T9775/T9775_fail.run T9775_fail [normal] (pre_cmd failed: 2) ../../libraries/process/tests/T9775/T9775_good.run T9775_good [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) }}} That's an uncomfortably long list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:44:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:44:22 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.8cd932d8894853df93b65d581d8f25e1@haskell.org> #9173: Better type 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 simonpj): I'd love us to try this. It could be a very helpful and (I think) insightful warm-up project for someone wanting to get to know GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:48:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:48:52 -0000 Subject: [GHC] #15108: Panic: collectNBinders Message-ID: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Keywords: panic | Operating System: Linux collectNBinders | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists. Steps to reproduce: `stack.yaml`: {{{ resolver: nightly-2018-04-30 }}} `bug.cabal`: {{{ name: bug version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library build-depends: base default-language: Haskell2010 executable bug main-is: Main.hs build-depends: base , bug default-language: Haskell2010 }}} `Main.hs`: {{{ module Main where main :: IO () main = do _ <- return $ getInt Circle return () newtype MyInt = MyInt Int data Shape = Circle | Square getInt :: Shape -> MyInt getInt sh = case sh of Circle -> let (MyInt i) = MyInt 3 in myInt i Square -> let (MyInt i) = MyInt 2 in myInt i where myInt = MyInt }}} Then run: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ stack build --profile bug-0.1.0.0: build (lib + exe) Preprocessing library for bug-0.1.0.0.. Building library for bug-0.1.0.0.. Preprocessing executable 'bug' for bug-0.1.0.0.. Building executable 'bug' for bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package bug-0.1.0.0 using: /usr/local/home//.stack/setup-exe-cache/x86_64-linux- tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build lib:bug exe:bug --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:54:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:54:00 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.aa23cef3bdce1fd49e10df0b2348d1db@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders 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: | -------------------------------------+------------------------------------- Description changed by cdisselkoen: Old description: > GHC 8.4.2 panics with the error message `collectNBinders`, when compiling > with profiling. This is a very similar bug to #15002, but although > #15002 is fixed in 8.4.2, this panic persists. > > Steps to reproduce: > > `stack.yaml`: > {{{ > resolver: nightly-2018-04-30 > }}} > > `bug.cabal`: > {{{ > name: bug > version: 0.1.0.0 > build-type: Simple > cabal-version: >=1.10 > > library > build-depends: base > default-language: Haskell2010 > > executable bug > main-is: Main.hs > build-depends: base > , bug > default-language: Haskell2010 > }}} > > `Main.hs`: > {{{ > module Main where > > main :: IO () > main = do > _ <- return $ getInt Circle > return () > > newtype MyInt = MyInt Int > > data Shape = Circle > | Square > > getInt :: Shape -> MyInt > getInt sh = > case sh of > Circle -> > let (MyInt i) = MyInt 3 > in myInt i > Square -> > let (MyInt i) = MyInt 2 > in myInt i > where > myInt = MyInt > }}} > > Then run: > {{{ > $ stack ghc -- --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ stack build --profile > bug-0.1.0.0: build (lib + exe) > Preprocessing library for bug-0.1.0.0.. > Building library for bug-0.1.0.0.. > Preprocessing executable 'bug' for bug-0.1.0.0.. > Building executable 'bug' for bug-0.1.0.0.. > [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 > -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.2 for x86_64-unknown-linux): > collectNBinders > 1 > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in > ghc:CoreSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > -- While building custom Setup.hs for package bug-0.1.0.0 using: > /usr/local/home//.stack/setup-exe-cache/x86_64-linux- > tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- > work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build lib:bug exe:bug > --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > }}} New description: GHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists. Steps to reproduce: `stack.yaml`: {{{ resolver: nightly-2018-04-30 }}} `bug.cabal`: {{{ name: bug version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable bug main-is: Main.hs build-depends: base default-language: Haskell2010 }}} `Main.hs`: {{{ module Main where main :: IO () main = do _ <- return $ getInt Circle return () newtype MyInt = MyInt Int data Shape = Circle | Square getInt :: Shape -> MyInt getInt sh = case sh of Circle -> let (MyInt i) = MyInt 3 in myInt i Square -> let (MyInt i) = MyInt 2 in myInt i where myInt = MyInt }}} Then run: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ stack build --profile bug-0.1.0.0: build (lib + exe) Preprocessing library for bug-0.1.0.0.. Building library for bug-0.1.0.0.. Preprocessing executable 'bug' for bug-0.1.0.0.. Building executable 'bug' for bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package bug-0.1.0.0 using: /usr/local/home//.stack/setup-exe-cache/x86_64-linux- tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build lib:bug exe:bug --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 22:55:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 22:55:33 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.942fa3838ced83cb0b0d5b8446f3170d@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders 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: | -------------------------------------+------------------------------------- Description changed by cdisselkoen: Old description: > GHC 8.4.2 panics with the error message `collectNBinders`, when compiling > with profiling. This is a very similar bug to #15002, but although > #15002 is fixed in 8.4.2, this panic persists. > > Steps to reproduce: > > `stack.yaml`: > {{{ > resolver: nightly-2018-04-30 > }}} > > `bug.cabal`: > {{{ > name: bug > version: 0.1.0.0 > build-type: Simple > cabal-version: >=1.10 > > executable bug > main-is: Main.hs > build-depends: base > default-language: Haskell2010 > }}} > > `Main.hs`: > {{{ > module Main where > > main :: IO () > main = do > _ <- return $ getInt Circle > return () > > newtype MyInt = MyInt Int > > data Shape = Circle > | Square > > getInt :: Shape -> MyInt > getInt sh = > case sh of > Circle -> > let (MyInt i) = MyInt 3 > in myInt i > Square -> > let (MyInt i) = MyInt 2 > in myInt i > where > myInt = MyInt > }}} > > Then run: > {{{ > $ stack ghc -- --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ stack build --profile > bug-0.1.0.0: build (lib + exe) > Preprocessing library for bug-0.1.0.0.. > Building library for bug-0.1.0.0.. > Preprocessing executable 'bug' for bug-0.1.0.0.. > Building executable 'bug' for bug-0.1.0.0.. > [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 > -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.2 for x86_64-unknown-linux): > collectNBinders > 1 > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in > ghc:CoreSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > -- While building custom Setup.hs for package bug-0.1.0.0 using: > /usr/local/home//.stack/setup-exe-cache/x86_64-linux- > tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- > work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build lib:bug exe:bug > --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > }}} New description: GHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists. Steps to reproduce: `stack.yaml`: {{{ resolver: nightly-2018-04-30 }}} `bug.cabal`: {{{ name: bug version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable bug main-is: Main.hs build-depends: base default-language: Haskell2010 }}} `Main.hs`: {{{ module Main where main :: IO () main = do _ <- return $ getInt Circle return () newtype MyInt = MyInt Int data Shape = Circle | Square getInt :: Shape -> MyInt getInt sh = case sh of Circle -> let (MyInt i) = MyInt 3 in myInt i Square -> let (MyInt i) = MyInt 2 in myInt i where myInt = MyInt }}} Then run: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ stack build --profile bug-0.1.0.0: configure (exe) Configuring bug-0.1.0.0... bug-0.1.0.0: build (exe) Preprocessing executable 'bug' for bug-0.1.0.0.. Building executable 'bug' for bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package bug-0.1.0.0 using: /usr/local/home/cdisselk/.stack/setup-exe-cache/x86_64-linux- tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build exe:bug --ghc- options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 23:01:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 23:01:15 -0000 Subject: [GHC] #15096: GHC fails to execute gcc on Windows when unicode character is in the path In-Reply-To: <042.e5997dea2909a753cc3e4428c3168ba3@haskell.org> References: <042.e5997dea2909a753cc3e4428c3168ba3@haskell.org> Message-ID: <057.b1e92d9689875875137647bb9f79108e@haskell.org> #15096: GHC fails to execute gcc on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #15021 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lehins): This seems very much related. If the `.hs` file has unicode chars in it, compilation will fail on Windows (regardless of the code page setting): {{{ PS C:\phab> ghc Я.hs [1 of 1] Compiling Main ( ?.hs, ?.o ) Assembler messages: Fatal error: can't create ?.o: Invalid argument `gcc.exe' failed in phase `Assembler'. (Exit code: 1) PS C:\phab> chcp 65001 Active code page: 65001 PS C:\phab> ghc Я.hs [1 of 1] Compiling Main ( Я.hs, Я.o ) Assembler messages: Fatal error: can't create ?.o: Invalid argument `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 30 23:40:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Apr 2018 23:40:14 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.63661b21cd8ebb625079de0609fb2455@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Ömer, thanks for the excellent sleuthing and the very clear explanation of what had gone awry. It sounds like the crash I have been experiencing will be fixed in GHC 8.6 (and that someone may resolve the longstanding #9718). What I don’t fully grasp is the set of circumstances under which this error manifests itself. Based on my reading of the explanation, it seems like this would happen any time there was a pattern match on an unboxed sum in which none of the cases referenced a CAF. But that doesn’t seem right, because that would mean that this error would happen all the time. The reason I am interested in understanding this is because I would like to know if there is a subset of programs in which unboxed sums can safely be used. Or, as a library author, is it currently impossible to use unboxed sums in such a way that the end user cannot induce the failure case? -- Ticket URL: GHC The Glasgow Haskell Compiler