From ghc-devs at haskell.org Tue Aug 1 00:43:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 00:43:15 -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.e82d488b99c81bf508a6bfd721e44f8b@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: 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 angerman): * cc: angerman (added) Comment: This is already in the aarch64/mach-o linker. And I believe the aarch64/elf linker could possibly be doing this already as well. Feel free to query me on IRC:angerman, or twitter:angerman_io. Otherwise if no one picks this up, I'll try to get around to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 01:16:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 01:16:02 -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.55e31a2002f9e448249ad30a163341b9@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I'm currently cleaning up the branch before submitting a Diff. > Well, 2.6% improvement in runtime is quite sizeable. The runtime numbers are probably unreliable because I didn't try to keep machine unloaded while running nofib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 02:23:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 02:23:31 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.5bb27e121240755bc44104393ecef7db@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): Replying to [comment:4 bgamari]: > Hmm, this is quite odd; I have no such problem while compiling `lens` with `-fuse-ld=gold` on FreeBSD 11.0 (amd64) (although with gcc 4.8.5) This is probably because gcc48 didn't invoke ld.gold as the linker. {{{ 5225 ghc GIO fd 16 read 866 bytes "COLLECT_GCC=/usr/local/bin/gcc48 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc48/gcc/x86_64-portbld- freebsd11.1/4.8.5/lto-wrapper Target: x86_64-portbld-freebsd11.1 Configured with: /var/ports/basejail/usr/ports/lang/gcc48/work/gcc-4.8.5/configure --with- build-config=bootstrap-debug -\ -disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc48 --libexecdir=/usr/local/libexec/gcc48 --progra\ m-suffix=48 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc48/include/c++/ -\ -with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --disable-libgcj --enable-lan\ guages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc\ 48 --build=x86_64-portbld-freebsd11.1 Thread model: posix gcc version 4.8.5 (FreeBSD Ports Collection) " }}} Notice that line `--with-ld=...` above, if you installed gcc48 from ports, \\ then it's configured with `--with-ld=/usr/local/bin/ld`. Also, {{{ 5225 ghc RET kevent 1 5225 ghc CALL read(0x10,0x80d541010,0x2000) 5225 ghc GIO fd 16 read 608 bytes "collect2 version 4.8.5 /usr/local/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld- elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc\ 48/gcc/x86_64-portbld-freebsd11.1/4.8.5/crtbegin.o -L/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.1/4.8.5 -L/usr/lo\ cal/lib/gcc48/gcc/x86_64-portbld- freebsd11.1/4.8.5/../../../../../x86_64-portbld-freebsd11.1/lib -L/usr/local/lib/gcc48/\ gcc/x86_64-portbld-freebsd11.1/4.8.5/../../.. --version -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -\ lgcc_s --no-as-needed /usr/local/lib/gcc48/gcc/x86_64-portbld- freebsd11.1/4.8.5/crtend.o /usr/lib/crtn.o " }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 02:28:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 02:28:40 -0000 Subject: [GHC] #14068: Turn tail-recursive functions into recursive jointpoints In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.afd4988529903e2aba3d91e6a52f7ee4@haskell.org> #14068: Turn tail-recursive functions into recursive jointpoints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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: #13966 #14067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just noting down some thoughts. How does this work for mutually recursive bindings? {{{ let f x y = case y of A -> f x' y' B -> g (x', y') C -> e3 g p = case p of (x, y) -> f x' y' in f 1 2 + g 3 4 }}} Here `f` and `g` look like they might be join points. One way of doing that would be {{{ let f x y = joinrec $j1 x y = case y of A -> $j1 x' y' B -> $j2 (x', y') C -> e3 $j2 p = case p of (x, y) -> f x' y' in $j1 x y g p = joinrec $j1 x y = case y of A -> $j1 x' y' B -> $j2 (x', y') C -> e3 $j2 p = case p of (x, y) -> f x' y' in $j2 p in f 1 2 + g 3 4 }}} but such code duplication is clearly not desired. The next best thing I can think of is some encoding {{{ let f_g arg = joinrec $j1 x y = case y of A -> $j1 x' y' B -> $j2 (x', y') C -> e3 $j2 p = case p of (x, y) -> f x' y' in case arg of Left (x,y) -> $j1 x y Right p -> $j2 p f x y = f_h (Left (x,y)) g p = f_g (Right p) in f 1 2 + g 3 4 }}} (maybe using unboxed sums for the parameter encoding). This would have the desired effect, but I guess it goes too far. So I conclude this ticket should focus on the singly recursive case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 02:44:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 02:44:59 -0000 Subject: =?utf-8?b?W0dIQ10gIzE0MDcwOiBBbGxvdyDigJh1bnNhZmXigJkgZGVyaXZp?= =?utf-8?q?ng_strategy=2C_deriving_code_with_=E2=80=98unsafeCoerc?= =?utf-8?b?ZeKAmQ==?= Message-ID: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This {{{#!hs newtype M m a = M (m a) deriving newtype Functor }}} produces something similar to {{{#!hs instance Functor m => Functor (M m) where fmap :: forall a a'. (a -> a') -> (M m a -> M m a') fmap = coerce (fmap @m @a @a') }}} but as wiki:Roles2 points out, this fails for methods such as `join_`: {{{#!hs class MonadJoin m where join_ :: m (m a) -> m a newtype M m a = M (m a) deriving newtype MonadJoin -- Couldn't match representation of type ‘m (M m a)’ with that of ‘m (m a)’ }}} I think the user should be given the option to respect the roles or not by supplying `unsafe` wiki:Commentary/Compiler/DerivingStrategies {{{#!hs newtype M m a = M (m a) deriving unsafe newtype MonadJoin -- -( Produces `unsafeCoerce' instead of `coerce' )- -- instance MonadJoin m => MonadJoin (M m) where -- join_ :: forall a. M m (M m a) -> M m a -- join_ = unsafeCoerce (join_ @m @a) }}} This lets us (`newtype`-) derive a host of instances that we currently can not: `Traversable`, `Distributive` (currently forbidden due to [https://hackage.haskell.org/package/distributive-0.5.2/docs/Data- Distributive.html#v:distribute distribute]), [https://hackage.haskell.org/package/linear-1.20.7/docs/Linear- Matrix.html#v:trace Trace], [http://hackage.haskell.org/package/profunctors-5/docs/Data-Profunctor- Monad.html ProfunctorMonad / ProfunctorComonad], ... It does not seem like lenses (`FunctorWithIndex`, `FoldableWithIndex`, `TraversableWithIndex`) work with this though -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 02:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 02:57:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.c329d2f348784608fb721b90bc056cc9@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This would be an escape hatch like `unsafeCoerce`, until roles get improved -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 03:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 03:40:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.88ec8a38bf4251aa1ebb4492935a0b42@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I will admit that the devil on my shoulder is trying to coax me into implementing this idea. But at the same time, the angel on my other shoulder is saying I should wait until we have `QuantifiedContexts`, which would give us a principled solution to this problem. I'm unable to pick a side at the moment, so I'll simply wait until I've heard more feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 03:51:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 03:51:20 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.1caecaab9ccea7c1adc7e3d22a94b139@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I looked into this some more tonight. While I wasn't able to find the underlying cause of why `COMPLETE` sets don't seem to quite work for data family instances, I did notice a discrepancy between pattern synonyms for datatype contructors and those for data family instance constructors. In several places throughout GHC, the `conLikeResTy` function is used to determine the return type of a conlike (be it a proper data constructor or a pattern synonym). For datatype constructors, `conLikeResTy` returns something of the form `T a1 ... an`, where `T` is a datatype tycon. This holds true regardless of whether `conLikeResTy` is called on a proper data constructor (e.g., the `MkT` in `data T a = MkT a`) or a pattern synonym for a data constructor (e.g., `pattern FakeT a = MkT a`). With data family instances, however, the story is a little different. Let's suppose we have: {{{#!hs data family F a b data instance F Int b = MkF Int pattern FakeF a = MkF a }}} If you call `conLikeResTy` on `MkF`, you won't get `F Int b`, but instead something like `R:FInt b`, where `R:FInt` is the //representation// tycon for the data family instance `F Int b` (as opposed to `F`, which is the //parent// data family tycon). However, calling `conLikeResTy` on `FakeF` gives you `F Int b` instead! That's a difference that smells quite funny to me, but I haven't tracked down the scent's origin yet. For what it's worth, `COMPLETE` sets group conlikes by parent tycon name, not by representation tycon name, so for instance: {{{#!hs {-# COMPLETE SFalse, STooGoodToBeTrue :: Sing #-} }}} In order to look up these conlikes, you'd need to use `Sing (z :: Bool)`, not `R:SingzBool` (type weirdness in comment:1 aside). What does it all mean? I can't be sure at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 04:25:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 04:25:01 -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.8a660bfb456c186447fb82c346357299@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): Ben, thank you for adding me to the loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 05:11:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 05:11:15 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.db845644533eb8f6cee963ed06deb4a5@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zaoqi): Replying to [comment:7 winter]: > 对于帮助类的问题，还请使用 Haskell-cafe 邮件组（对于初学者相当友好）。或 者去知乎、segmentfault这样的网站（尤其是中文类的问题），Ghc trac主要是用来 反馈 bug 或者提出特性需求的，所以如果你还是认为 GHC 存在 bug 的话，请解释 你希望你的程序做什么，仅仅贴出代码的话我们很难给出解释，于是你也会很难理解 。 我需要能判断是否有`instance Eq a`，在运行时。 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 06:07:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 06:07:57 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.abf5301db005aa5a6dd5de7c298e0831@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:8 zaoqi]: > 我需要能判断是否有`instance Eq a`，在运行时。 > Google translate: I need to be able to judge whether there is `instance Eq a` at run time No: '''You''' must explain why you refuse to change the definition of `Dyn`. Google translate: 否：你必須解釋為什麼你拒絕改變 `Dyn` 的定義。 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:12:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:12:19 -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.d8a5a052b31388a48eec532c5ce1389f@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, PartialTypeSignatures 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): OK I understand the problem. Consider the type signature (abbreviated from the one written) {{{ -- Sing :: forall (a:*). WeirdList a -> * elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -- p @ (WeirdList z) (_ :: WeirdList z) xs -> p _ (WeirdCons x xs)) -> p _ wl }}} I have written ou the explicitly kind application needed in the application `(p _ xs)`. Now remember that a signature with wildcards is like a template imposed on type inference. The `_` wildcards are replaced with unification variables. So it's like this {{{ alpha1 :: kappa1 alpha2 :: kappa2 alpha3 :: kappa3 elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p alpha1 xs -- p @ (WeirdList z) (alpha1 :: WeirdList z) xs -> p alpha2 (WeirdCons x xs)) -> p alpah3 wl }}} These unification variables are at the "top" of the type. Once you see this it is clear that simply kind-checking this type should fail, becuase `alpha` must have kind `WeirdList z`, and `z` is bound by that inner forall. Yikes! This is all happening because we aren't generating an implication constraint when we kind-check a forall. In fact, there are other symptoms of the same problem: see #14066. Let's cure that first, and then come back to this one (which might "just work"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:18:12 -0000 Subject: [GHC] #14068: Turn tail-recursive functions into recursive jointpoints In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.55b7d400b83ea15f20130736cbadd2c9@haskell.org> #14068: Turn tail-recursive functions into recursive jointpoints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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: #13966 #14067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The function > {{{ > let f x y = case y of > A -> f x' y' > B -> e2 > C -> e3 > in g f > }}} > is not turned into a recursive join point, because the call to `f` is not > in tail call position. But the recursive calls are, and these matter > performance-wise! Hence, it would be beneficial to turn this into > {{{ > let f x y = joinrec $j x y = case x y of > A -> $j x' y' > B -> e2 > C -> e3 > in $j x y > in g f > }}} > > This has the additional effect that now `f` is no longer recursive and > may get inlined. > > This came up in #13966, and might go well with #14067. New description: The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. It also came up in #13966, and might go well with #14067. It might work well with #13051. -- Comment (by simonpj): This is a dup of -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:18:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:18:56 -0000 Subject: [GHC] #13567: Do loopification using join points In-Reply-To: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> References: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> Message-ID: <061.236aa9a0b8ce4f69616d7179be6656ed@haskell.org> #13567: Do loopification using join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | 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 simonpj): * status: new => closed * resolution: => duplicate Comment: Closing in favour of a new dup, #14068, which has a bit more info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:20:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:20:50 -0000 Subject: [GHC] #14068: Loopification using join points (was: Turn tail-recursive functions into recursive jointpoints) In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.256adf367215e9f5cc111aee2163a90d@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints Old description: > The function > {{{ > let f x y = case y of > A -> f x' y' > B -> e2 > C -> e3 > in g f > }}} > is not turned into a recursive join point, because the call to `f` is not > in tail call position. But the recursive calls are, and these matter > performance-wise! Hence, it would be beneficial to turn this into > {{{ > let f x y = joinrec $j x y = case x y of > A -> $j x' y' > B -> e2 > C -> e3 > in $j x y > in g f > }}} > > This has the additional effect that now `f` is no longer recursive and > may get inlined. > > This came up in #13966, and might go well with #14067. New description: The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. It came up in #13966, and might go well with #14067. It might work well with #13051, which Thomas Jakway is still thinking about. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:21:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:21:50 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.b2ccd0263387594ce155820c9017f5c2@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I agree: stick to the singly-recursive case. Make sure we do this at top level too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:24:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:24:09 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.c6dc29489bde9d6701e2e5e20c5c8b9d@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > The function > {{{ > let f x y = case y of > A -> f x' y' > B -> e2 > C -> e3 > in g f > }}} > is not turned into a recursive join point, because the call to `f` is not > in tail call position. But the recursive calls are, and these matter > performance-wise! Hence, it would be beneficial to turn this into > {{{ > let f x y = joinrec $j x y = case x y of > A -> $j x' y' > B -> e2 > C -> e3 > in $j x y > in g f > }}} > > This has the additional effect that now `f` is no longer recursive and > may get inlined. > > The idea is described under "New idea: use join points" in > [wiki:Commentary/Compiler/Loopification]. > > It came up in #13966, and might go well with #14067. > > It might work well with #13051, which Thomas Jakway is still thinking > about. New description: The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. Some notes: * We should to this both at top level and for nested definitions. * We can remove the "loopification" code from the code generator when this is done. * It came up in #13966, and might go well with #14067. * It might work well with #13051, which Thomas Jakway is still thinking about. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:30:55 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.74744df108a7341119744496849cf7e1@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, two tasks. Of these, the most important is the first #14068. The second SAT part is worthwhile, I think, but this particular ticket doesn't really show why. The point is that while SAT is ''sometimes'' good for normal definitions, I think it's probably ''always'' good (or at least not harmful) for `joinrecs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:33:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:33:12 -0000 Subject: [GHC] #14071: Porting GHC to Scheme without side-effecting Message-ID: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> #14071: Porting GHC to Scheme without side-effecting -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:37:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:37:11 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.70f943b24e1f1e327e6da5951ce03384@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zaoqi): Replying to [comment:9 AntC]: > Replying to [comment:8 zaoqi]: > > 我需要能判断是否有`instance Eq a`，在运行时。 > > > Google translate: I need to be able to judge whether there is `instance Eq a` at run time > > No: '''You''' must explain why you refuse to change the definition of `Dyn`. > > Google translate: 否：你必須解釋為什麼你拒絕改變 `Dyn` 的定義。 instance Show Dyn instance Enum Dyn instance Num Dyn ...... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 07:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 07:41:31 -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.534eef81160db8fbc46fb1d73640424e@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: nomeata (added) Comment: I still feel that this is the Right Thing To Do. The performance results are not so exciting... but it would not surprise me if there was more to be had. > I'm currently cleaning up the branch before submitting a Diff. Great. I'd like Joachim to review your code, if he is willing; after all, he had the first go at this. And sometimes a review leads to improvements and clean ups. On your wiki page [wiki:NestedCPR/Akio2017] you speak of "nested strictness", "more aggressive worker/wrapper", "correct handling of strict contructor field", etc, but in each case I have little idea of what you mean. Could you expand with more specifics? Really I'd like to have a page describing the ''design''. (E.g. do you have a convergence analyser? Could we use that for other things?) Having such a description would make it much easier to read the code. There's a paper in here somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 08:35:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 08:35:42 -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.82d8d1d1f04891c2487ac2a2e6f7e0c3@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for characterising this so well. Here are some thoughts. * The `GlobalRdrEnv` maps an `OccName` to a `[GlobalRdrElt]`. This was designed to handle the case where there are a handful of things `A.f`, `B.f`, etc. in scope, all with unqualified name `f`. The list is not expected to be long. * But in this case, I believe that that the list is getting long; hence the problem. Adding a DEBUG warning for this situation would be good. * Why is the list getting long? Becuase we have {{{ ghci> let x = True -- Binds Ghci1.x ghci> let x = False -- Binds Ghci2.x ghci> let x = True -- Binds GHci3.x ...etc... }}} All those Ids are (rightly) kept in the `ic_tythings`. But they are ''also'' all kept in the `ic_rn_gbl_env`. (`Note [The interactive package]` in `HscTypes` and the following notes are of some help.) * I can't work out why we keep the shadowed `x`'s in the `ic_rn_gbl_env`. If we simply deleted them, all would be well. After all, '''we do not expect the user to be able to refer to an old `x` with a qualified name `Ghci1.x`'''. * But consider this: {{{ ghci> :load M -- Brings `x` and `M.x` into scope ghci> x ghci> "Hello" ghci> M.x ghci> "hello" ghci> let x = True -- Shadows `x` ghci> x -- The locally bound `x` -- NOT an ambiguous reference ghci> True ghci> M.x -- M.x is still in scope! ghci> "Hello" }}} So when we add `x = True` we must not delete the `M.x` from the `GlobalRdrEnv`; rather we just want to make it "qualified only"; hence the `mk_fake-imp_spec` in `shadowName`. * Side note: this is similar to the Template Haskell case, described in `Note [GlobalRdrEnv shadowing]` in `RdrName`. {{{ module M where f x = h [d| f = ....f....M.f... |] }}} In the declaration quote, the unqualified `f` should refer to the `f` bound by the quote, but the qualified `M.f` should refer to the top-level `f`. So we don't want to delete that top-level binding from the `GlobalRdrEnv`; we just want to make it "qualified only"; hence the `mk_fake-imp_spec` in `shadowName`. My conclusion: we want a way to delete from the `GlobalRdrEnv` things bound by GHCi (like `Ghci1.x`), which we do not want to refer to in a qualified way. How can we distinguish `Ghci1.x` from `M.x`? Two possibilities * Easy but a bit hacky: we can look at the package in the `Name`. * In some ways nicer: use the `is_qual` field of the `ImpDeclSpec`. Currently it's a `Bool`: * True => `M.x` in in scope, but `x` is not * False => Both `M.x` and `x` are in scope We could provide a third possibility, to say that `x` is in scope but `M.x` is not. We could use that for GHCi-bound Ids. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 08:36:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 08:36:50 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.b2c6e908ea61d59eaa524273f9d03b43@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is there an ETA on quantified contexts? Do they cover legitimate uses of '`UnsafeDeriving`' or are there cases where it would still be useful? If we must wait a few releases for quantified constraints to hit this can function as a stopgap solution, could be marked as experimental -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 08:41:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 08:41:55 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.db702c16362e7863eec5e3d3bb28a417@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Also are there cases where this can cause segfaults and the such -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 08:49:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 08:49:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.72d077fbdbdbcf06d859edd6d700643f@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: george.karachalias@…, tom.schrijvers@… (added) Comment: Let's just do `QuantifiedContexts`. Tom and George (cc'd) have a Haskell Symposium 2017 paper, and I think are motivated to push it into GHC. Richard and I are strongly supportive. No ETA though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 09:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 09:10:53 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.b6fb53f65fbdac22eb668715ab982914@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That sounds excellent, I'm thrilled about this feature. Incidentally is it possible to coerce `Lens s a = forall f. Functor f => (a -> f a)` types? {{{#!hs class X f where x :: Lens (f a) a newtype WrappedX f a = WrapX (f a) instance X f => X (WrappedX f) where x :: forall a. Lens (WrappedX f a) a x = unsafeCoerce x' where x' :: Lens (t a) a x' = x @t @a }}} fails with {{{ • Could not deduce (Functor f0) arising from a use of ‘x'’ from the context: X t bound by the instance declaration at /tmp/uuu.hs:21:10-25 or from: Functor f bound by the type signature for: x :: Functor f => (a -> f a) -> Foo t a -> f (Foo t a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 09:19:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 09:19:04 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.6f1dbfa175f333e3f82d47ef25ad23a7@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, you're right. What I should have said is this. There is no reason to allow data instances to be written under-saturated. That is, we could insist on {{{ data instance Sing (a :: Bool) where ... }}} But, as an additional feature, we allow you to drop any trailing patterns that are simply type variables (if not mentioned earlier). Thus {{{ data instance T Int [a] (c::*) (d::Bool) (e::*) where ... }}} can also be written equivalently {{{ data instance T Int [a] :: * -> Bool -> * -> * where ... }}} Is that right? If so, let's update the user manual to say so. Alas, we have a bug, I think. Consider {{{ data family T a b :: Type newtype instance T Int :: Type -> Type where MkT :: IO a -> T Int a deriving( Monad, Applicative, Functor ) }}} Oddly, this fails with {{{ Foo2.hs:38:13: error: • Can't make a derived instance of ‘Monad (T Int)’ (even with cunning GeneralizedNewtypeDeriving): cannot eta-reduce the representation type enough }}} Whereas this succeeds {{{ newtype instance T Int a :: Type where MkT :: IO a -> T Int a deriving( Monad, Applicative, Functor ) }}} so the two aren't (yet) quite equivalent. Do you agree this is a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 09:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 09:31:16 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.391ceaca8e3ce62189fc5a6ddf094026@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure either. But we do have worker/wrapper for ordinary data cons, so there is room to inject some coercions. Eg {{{ data T = MkT {-# UNPACK #-} !Int }}} We get a worker and a wrapper. {{{ MkT :: Int# -> T -- Worker -- No code; this is the real data constructor in Core $WMkT :: Int -> T -- Wrapper $WMkT x = case x of I# y -> MkT y }}} Occurrences of `MkT` in terms are replaced by `$WMkT`. In patterns we need some impedence matching. Can someone produce an example with some actual data constructors? I'm a bit lost as to the actual goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 11:24:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 11:24:26 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.2474770ccb87f23c2ce3c9ca03cb9dca@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): I rebuilt GHC 8.2.1 from source, it worked.\\ So I guess there might be some problem in the released binary package. Since it's an unofficial build, I am not sure if I could use it in production, especial after seeing some test failures. (I am fairly new to GHC building & testing) {{{ Unexpected results from: TEST="T3807 T5975a outofmem T9203 T11627b scc001 conc038 MultiLayerModules scc003 T5205 T2615 haddock.Cabal haddock.base fdReadBuf001 T1969 T5631 ffi014 T4850 linkwhole T13035 cgrun057 T5975b T12227 T10296a determ021 ffishutdown parsing001" SUMMARY for test run started at Tue Aug 1 18:52:08 2017 CST 0:12:51 spent to go through 5890 total tests, which gave rise to 26738 test cases, of which 20498 were skipped 70 had missing libraries 6063 expected passes 78 expected failures 3 caused framework failures 0 caused framework warnings 0 unexpected passes 17 unexpected failures 10 unexpected stat failures Unexpected failures: codeGen/should_run/cgrun057.run cgrun057 [bad stderr] (profasm) concurrent/should_run/conc038.run conc038 [exit code non-0] (threaded1) determinism/determ021/determ021.run determ021 [bad stdout] (normal) driver/linkwhole/linkwhole.run linkwhole [bad exit code] (normal) dynlibs/T3807.run T3807 [bad exit code] (normal) ffi/should_run/ffi014.run ffi014 [exit code non-0] (threaded1) profiling/should_run/scc001.run scc001 [bad profile] (profasm) profiling/should_run/scc003.run scc003 [bad profile] (profasm) profiling/should_run/scc003.run scc003 [bad profile] (prof) profiling/should_run/T11627b.run T11627b [bad heap profile] (profasm) profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hd) rts/T2615.run T2615 [bad stdout] (normal) rts/T4850.run T4850 [bad exit code] (normal) rts/ffishutdown.run ffishutdown [exit code non-0] (threaded1) rts/T10296a.run T10296a [bad exit code] (normal) rts/outofmem.run outofmem [bad exit code] (normal) ../../libraries/unix/tests/fdReadBuf001.run fdReadBuf001 [bad exit code] (ghci) Unexpected stat failures: perf/compiler/parsing001.run parsing001 [stat too good] (normal) perf/compiler/T1969.run T1969 [stat too good] (normal) perf/compiler/T5631.run T5631 [stat too good] (normal) perf/compiler/T12227.run T12227 [stat too good] (normal) perf/compiler/T13035.run T13035 [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat too good] (normal) perf/haddock/haddock.base.run haddock.base [stat too good] (normal) perf/haddock/haddock.Cabal.run haddock.Cabal [stat too good] (normal) perf/should_run/T5205.run T5205 [stat too good] (normal) perf/should_run/T9203.run T9203 [stat too good] (normal) Framework failures: ghci/scripts/T5975a.run T5975a [ghci] ('ascii' codec can't encode characters in position 41-42: ordinal not in range(128)) ghci/scripts/T5975b.run T5975b [ghci] ('ascii' codec can't encode characters in position 41-42: ordinal not in range(128)) perf/compiler/MultiLayerModules.run MultiLayerModules [normal] (pre_cmd failed: 127) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:15:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:15:14 -0000 Subject: [GHC] #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 Message-ID: <047.529482d8a6c8603cd451dd6b6b1e8cd0@haskell.org> #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Unicode normalization library (https://github.com/harendra-kumar/unicode- transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. On the other hand, when compared to GHC 7.8.4, GHC 8.2.1 is marginally better. This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. I filed a couple of ghc trac tickets earlier on that. You can reproduce these results easily as follows: {{{ $ git clone https://github.com/harendra-kumar/unicode-transforms.git $ git checkout -b v0.3.3 v0.3.3 $ echo ghc-8.0 $ stack bench $ stack bench --stack-yaml stack-7.10.yaml $ stack bench --stack-yaml stack-8.2.yaml }}} Here are some excerpts from the benchmarks: GHC 7.10.3: {{{ benchmarking unicode-transforms-text/NFD/English time 4.823 ms (4.765 ms .. 4.902 ms) benchmarking unicode-transforms-text/NFD/Deutsch time 5.607 ms (5.522 ms .. 5.673 ms) }}} GHC 8.0.1 {{{ benchmarking unicode-transforms-text/NFD/English time 6.330 ms (6.232 ms .. 6.439 ms) benchmarking unicode-transforms-text/NFD/Deutsch time 7.109 ms (7.034 ms .. 7.183 ms) }}} GHC 8.2.1 {{{ benchmarking unicode-transforms-text/NFD/English time 5.659 ms (5.594 ms .. 5.740 ms) benchmarking unicode-transforms-text/NFD/Deutsch time 6.406 ms (6.329 ms .. 6.478 ms) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:36:17 -0000 Subject: [GHC] #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 In-Reply-To: <047.529482d8a6c8603cd451dd6b6b1e8cd0@haskell.org> References: <047.529482d8a6c8603cd451dd6b6b1e8cd0@haskell.org> Message-ID: <062.d7618233de1a1e2ae51b65af5f42809e@haskell.org> #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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): > I filed a couple of ghc trac tickets earlier on that. Can you be specific? Which tickets? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:49:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:49:14 -0000 Subject: [GHC] #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 In-Reply-To: <047.529482d8a6c8603cd451dd6b6b1e8cd0@haskell.org> References: <047.529482d8a6c8603cd451dd6b6b1e8cd0@haskell.org> Message-ID: <062.e8c59186e898d7f93bfe02b6ecbd675f@haskell.org> #14072: Code generated by GHC 8.2.1 faster than 8.0.1 but still somewhat slower than 7.10.3 -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 harendra): In a quest to extract every last drop of perf in this library so that I can beat the gcc version, I investigated the GHC generated code and filed these tickets #12231 and #12232. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:56:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:56:08 -0000 Subject: [GHC] #14007: CI builds for integer-simple variant of GHC for Windows In-Reply-To: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> References: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> Message-ID: <060.5301a55d68dd423e4573ee5fd95ba048@haskell.org> #14007: CI builds for integer-simple variant of GHC for Windows ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 varosi): This could be built automatically with planned improvements in build system of GHC for 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:56:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:56:55 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.1a714d0fdee70a29349cb5285f889f2b@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 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 varosi): Possible implementation for 8.4 via LLVM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:57:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:57:25 -0000 Subject: [GHC] #12397: Support for PDB debug information generation In-Reply-To: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> References: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> Message-ID: <060.167184a8cce5ffca468a9d6e6dee4a00@haskell.org> #12397: Support for PDB debug information generation -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Debugging) | 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 varosi): Possible implementation in 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:58:06 -0000 Subject: [GHC] #14058: Cannot bundle pattern synonym with exported data family In-Reply-To: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> References: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> Message-ID: <065.0a81e09756c20f9bf7ca37c4c5ce1d0a@haskell.org> #14058: Cannot bundle pattern synonym with exported data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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): Phab:D3808 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"29f07b1de78198fa29dabafd7bf1f1f4ecdc7f54/ghc" 29f07b1d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29f07b1de78198fa29dabafd7bf1f1f4ecdc7f54" Allow bundling pattern synonyms with exported data families Test Plan: make test TEST=T14058 Reviewers: mpickering, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14058 Differential Revision: https://phabricator.haskell.org/D3808 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:58:06 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.35efdb1e1f10d0c2b8069dbcb973975e@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3805 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5a7af95ad2ce38e4b80893d869948c630454683b/ghc" 5a7af95a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a7af95ad2ce38e4b80893d869948c630454683b" KnownUniques: Handle DataCon wrapper names For some reason these weren't handled. I seem to remember thinking I had a reason for omitting them when writing the original patch, but I don't recall what that reason was at this point and clearly workers do show up in interface files. Test Plan: Validate against T14051 Reviewers: austin Subscribers: rwbarton, thomie, RyanGlScott GHC Trac Issues: #14051 Differential Revision: https://phabricator.haskell.org/D3805 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 12:58:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 12:58:24 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.269b84e6ce0754fa44fe5cf407f330a2@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Possible discussion for 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 13:13:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 13:13:01 -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.4a49a4864b8ce22195752e3ffcd42bdd@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Let me know when the branch is cleaned up. I can have a look (although I probably forgot everything since then…). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 13:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 13:31:09 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.e026e182c293fea88f510f45d8d5977f@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > We can remove the "loopification" code from the code generator when this is done. Ok, so I remembered correctly that, in the end, such code already today produces tight loops. So there are not immediate performance benefits to be gained from this transformation, because we just do loopification earlier, but possible knock-on effects due to inlining or (eventually) joinrec-SAT, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 14:04:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 14:04:06 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.4084fcf1c9100cccaaacd6de51ac64c6@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, there are immediate perf benefits: #13966 is one such case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 14:09:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 14:09:28 -0000 Subject: [GHC] #14071: Porting GHC to Scheme without side-effecting In-Reply-To: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> References: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> Message-ID: <059.e0dbd2f1d1f659c3e5412d02c8901abb@haskell.org> #14071: Porting GHC to Scheme without side-effecting -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I'm afraid I don't understand. Are you suggesting we port the compiler from Haskell to Scheme? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 14:39:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 14:39:11 -0000 Subject: [GHC] #14073: Testsuite should pass even with LANG=C Message-ID: <046.b3a4ecbca8e2acc4b47c372f158ea50a@haskell.org> #14073: Testsuite should pass even with LANG=C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- It seems that our testsuite has some sensitivity to the setting of the `LANG` environment variable. Namely the driver seems to encounter encoding issues in a few cases, {{{ Framework failures: ghci/scripts/T5975a.run T5975a [ghci] ('ascii' codec can't encode characters in position 41-42: ordinal not in range(128)) ghci/scripts/T5975b.run T5975b [ghci] ('ascii' codec can't encode characters in position 41-42: ordinal not in range(128)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 14:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 14:39:18 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.4b8a6ab29fc4ac894da8a040b17bd1da@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: 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): Sigh. This has turned out to be much nastier than I expected. I worked solely on {{{ import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} foo :: [Char] -> Bool foo = Strict.evalState mtlStateListParser_a }}} I'll refer to `mtlStateListParser_a` as `msp`. * Yes, comment:9 is right; the right path is to make `doFloatFromRhs` return `False` for bindings with a stable unfolding. * Even when that is done, the occurrence analyser does a bad job. We get {{{ Rec { msp = ... lvl ... {-# INLINE = ..msp.. #-} -- The stable unfolding lvl = ...msp... } }}} The occurrence analyser treats the occurrence of `lvl` as a "weak" reference, and so sorts into SCCs thus: `Rec{ msp }, NonRec { lvl }`. So then it stupidly marks `msp` as a loop breaker, and `lvl` as a weak loop breaker. In this case they'd be better in one SCC, in which case we'd pick `msp` (but not `lvl`) as a loop breaker. The relevant change is in `OccurAnal`, around line 1280. {{{ -- Find the "nd_inl" free vars; for the loop-breaker phase inl_fvs = udFreeVars bndr_set rhs_usage1 `unionVarSet` case mb_unf_uds of Nothing -> emptyVarSet -- udFreeVars bndr_set rhs_usage1 -- No INLINE, use RHS Just unf_uds -> udFreeVars bndr_set unf_uds }}} But I'm not fully confident of this change. * Even if we fix that, then the strictness analyser fails. We end up with {{{ msp = (\ (s::[Char]). case s of p1 -> (False, x) p2 -> (msp |> sym co) s' ) |> co }}} Those casts are enough to kill demand analysis. It was relying on the coercion-floating that we nuked in comment:9! The function looks to the demand analyser as if it has arity zero, and so we get no useful strictness. Yes, we could teach the demand analyser more tricks, but the tail is beginning to wag the dog. * This is all stupid. An INILNE pragma on a recursive function is doing no good at all. Maybe we should just discard it. And indeed that makes things work. * Until you use an INLINABLE pragma! We don't want to discard the INLINEABLE pragama on a recursive function -- it is super-useful. But if we don't the same ills happen as with INLINE. Actually, the specialiser propagates an INLINE pragma to the specialised function, but does '''not''' propagate an INLINEABLE pragam. Result: if you give an overloaded signature for `msp`, the specialiser will create a pragma-free specialised version, which will optimise nicely. But if you give a non-overloaded signature `msp :: Strict.State [Char] Bool`, the function fails to optimise for the reasons above. Mind you, in the latter case the INLINEABLE pragma is just as useless as the INLINE pragma was. This is ridiculously terrible. The pragmas(which are there to optimise the program) are getting in the way of optimising the function itself. What to do? Here's a simple idea; * Discard INLINE pragmas for recursive, or mutually recursive, functions. (You can do this manually too!) * Peel off a top-level function for INLINEABLE pragmas, thus: {{{ Rec { f = e[f] {-# INLINEABLE = e[f] #-} } ===> Rec { f' = e[f'] } Rec { f = f' {-# INLINEABLE = e[f] #-} } }}} The first `Rec` is a pragma-free group. The second has all its pragmas (for later clients), but just indirect to the first group if you actually call it. Alas, you can't do this manually right now. But somehow none of this really feels right. I'm not sure what to do, so I'm just brain-dumping this. Maybe someone else will have better ideas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 14:57:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 14:57:15 -0000 Subject: [GHC] #14074: fdReadBuf001 fails non-deterministically on FreeBSD Message-ID: <046.ae77a7184cfbb10e979a4af696339e6e@haskell.org> #14074: fdReadBuf001 fails non-deterministically on FreeBSD --------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- With this patch to `libraries/unix`, {{{#!patch diff --git a/tests/fdReadBuf001.hs b/tests/fdReadBuf001.hs index 4c121a2..f987c94 100644 --- a/tests/fdReadBuf001.hs +++ b/tests/fdReadBuf001.hs @@ -21,7 +21,7 @@ main = do r <- fdReadBuf rd p block let (chunk,rest) = splitAt (fromIntegral r) text chars <- peekArray (fromIntegral r) p - when (chars /= chunk) $ error "mismatch" + when (chars /= chunk) $ error $ "mismatch: expected="++show chunk++", found="++show chars when (null rest) $ exitWith ExitSuccess loop rest loop bytes }}} `fdReadBuf001` sometimes fails under the ghci way on FreeBSD 11.0 with something like, {{{ =====> fdReadBuf001(ghci) 1 of 1 [0, 0, 0] cd "../../libraries/unix/tests/fdReadBuf001.run" && "/home/ben/ghc-8.2.1/bin/ghc" fdReadBuf001.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 --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -package unix< fdReadBuf001.genscript Wrong exit code for fdReadBuf001(ghci) (expected 0 , actual 1 ) Stderr ( fdReadBuf001 ): fdReadBuf001: mismatch: expected=[101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,12 0,121,122,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112], found=[168,149,144,14,8,0,0,0,58,1,0,0,0,0,0,0,32,228,123,10,8,0,0,0,200,149,144,14,8,0,0,0,0,150,144,14,8,0,0,0,96,127,174,10,8,0,0,0,33,152,144,14,8,0,0,0,0,150,144,14,8,0,0,0,42,0,0,0,0,0,0,0,96,127,174,10,8,0,0,0,162,21,74,13,8,0,0,0,56,150,144,14,8,0,0,0,96,127,174,10,8,0,0,0,10,152,144,14,8,0,0,0,56,150,144,14,8,0,0,0,32,228,123,10,8,0,0,0,200,149,144,14,8,0,0,0,112,150,144,14,8,0,0,0,112,209,123,10,8,0,0,0,138,150,144,14,8,0,0,0,88,150,144,14,8,0,0,0,96,127,174,10,8,0,0,0,249,150,144,14,8,0,0,0,48,187,247,9,8,0,0,0,129,223,208,10,8,0,0,0,96,127,174,10,8,0,0,0,9,151,144,14,8,0,0,0,16,46,250,9,8,0,0,0,184,150,144,14,8,0,0,0,224,227,123,10,8,0,0,0,111,0,0,0,0,0,0,0,8,246,255,9,8,0,0,0,111,0,0,0,0,0,0,0,224,0,194,9,8,0,0,0] CallStack (from HasCallStack): error, called at fdReadBuf001.hs:24:36 in main:Main }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:03:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:03:02 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.ef56a83c4978edb078267ff02887ffc4@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Notice that line `--with-ld=...` above, if you installed gcc48 from ports, then it's configured with `--with-ld=/usr/local/bin/ld`. Sure, but my understanding is that `-fuse-ld=gold` (which I have confirmed does get passed to `gcc`) should override this default. > Since it's an unofficial build, I am not sure if I could use it in production, especial after seeing some test failures. (I am fairly new to GHC building & testing) For better or worse this looks relatively "normal" for a FreeBSD build, * The "stat too good" errors can be safely ignored. These are merely due to how we track performance metrics (which is currently being reworked; see #12758) * The profile errors (`cgrun057`, `ssc001`, `ssc003`, `T11627b`) are a known issue which I've been meaning to look into. * The two `'ascii' code can't encode character` issues are because you have `LANG` set to a non-UTF-8 locale (which is really a GHC dbug; I've opened #14073 to track this). * IIRC the `outofmem` error is due to `--disable-large-address-space` * The `ffishutdown` issue is a bit surprising; I can't reproduce that one * `fdReadBuf001` seems to fail non-deterministically, which is a bit concerning; I'll need to look into this. Tracked as #14074 * I can't reproduce the `conc038` failure * `T3807` depends upon `libdl` which doesn't exist on FreeBSD; this is a bug in the test. * `determ021` seems to be merely a library version mismatch * There appears to be some linkage issues on FreeBSD that we need to look into; namely `linkwhole` and `T2615` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:18:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:18:33 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.aa06180dd31e9fbbd81c3e544284685a@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: mpickering => nomeata Comment: Some preliminary work in `wip/T14068` resp `Phab:D3811`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:40:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.c3024d6445a815d2fc8f9e67e00b0101@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): >Do they cover legitimate uses of '`UnsafeDeriving`' or are there cases where it would still be useful? My hunch is that just about every use case for this proposed `unsafe newtype` deriving strategy would be subsumed by the ability to have quantified contexts involving `Coercible`. To use your earlier example: {{{#!hs class MonadJoin m where join_ :: m (m a) -> m a newtype M m a = M (m a) deriving newtype MonadJoin }}} In a brave new quantified world, this would generate code to the effect of: {{{#!hs instance (forall a. Coercible (m (M m a)) (m (m a)), MonadJoin m) => MonadJoin (M m) where join_ = coerce @(forall a. m (m a) -> m a) @(forall a. M m (M m a) -> M m a) join_ }}} Where the `forall a. Coercible (m (M m a)) (m (m a))` bit is needed to convince the typechecker that one can `coerce` underneath `m` in the right spot. Another possible design for this would be to use an implication constraint instead: {{{#!hs instance (forall a b. Coercible a b => Coercible (m a) (m b), MonadJoin m) => MonadJoin (M m) where join_ = coerce @(forall a. m (m a) -> m a) @(forall a. M m (M m a) -> M m a) join_ }}} Would this always be the right thing to do? My gut feeling is "yes", since if you can coerce between `m (M m a)` and `m (m a)` (for any `a`), it feels like you should be able to coerce between `m a` and `m b` for _any_ pair of inter-`Coercible` types `a` and `b`. But I haven't worked out the full details yet, so this is purely speculation on my end for the time being. > Incidentally is it possible to coerce `Lens s a = forall f. Functor f => (a -> f a) -> (s -> f s)` types? Sure! The example you gave only doesn't typecheck because you didn't expand the `Lens` type synonym: {{{#!hs {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Unsafe.Coerce type Lens s a = forall f. Functor f => (a -> f a) -> (s -> f s) class X f where x :: Lens (f a) a newtype WrappedX f a = WrapX (f a) instance X t => X (WrappedX t) where x :: forall a f. Functor f => (a -> f a) -> WrappedX t a -> f (WrappedX t a) x = unsafeCoerce x' where x' :: (a -> f a) -> t a -> f (t a) x' = x @t @a }}} This is important, since the `f` needs to scope over both `x` and `x'`. In your example, the `f` tucked underneath the two occurrences of the `Lens` type synonyms were distinct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:44:03 -0000 Subject: [GHC] #14075: GHC panic with parallel make Message-ID: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13803, #13981 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following modules: {{{#!hs -- F.hs module F () where }}} {{{#!hs -- F.hs-boot module F where import O (O) newtype F = F () instance O F where }}} {{{#!hs -- O.hs module O (O) where class O a where }}} {{{#!hs -- V.hs module V () where import {-# SOURCE #-} F () }}} {{{#!hs -- V.hs-boot module V where }}} If I try to compile this with {{{ ghc -j2 F O V }}} I get {{{ [1 of 4] Compiling O ( O.hs, O.o ) [2 of 4] Compiling F[boot] ( F.hs-boot, F.o-boot ) [3 of 4] Compiling F ( F.hs, F.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170720 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 F which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find F 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: [r1hL :-> Identifier ‘$trModule’] 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} On the other hand {{{ ghc -j1 F O V }}} works just fine, and gives the expected {{{ [2 of 5] Compiling O ( O.hs, O.o ) [3 of 5] Compiling F[boot] ( F.hs-boot, F.o-boot ) [4 of 5] Compiling F ( F.hs, F.o ) F.hs-boot:7:1: error: ‘F.F’ is exported by the hs-boot file, but not exported by the module | 7 | newtype F = F () | ^^^^^^^^^^^^^^^^ F.hs:1:1: error: instance O.O F.F -- Defined at F.hs-boot:8:10 is defined in the hs-boot file, but not in the module itself | 1 | -- F.hs | ^ }}} The example is a little bit sick, in that the original code is not expected to compile. I run into this by accident when trying to construct a minimal example of the issue reported in #13803 (note that that bug is marked as closed, but the original issue reported there remains unfixed, I am trying to construct a minimal testcase for the original issue there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:45:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:45:42 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.aab8ddb902d914b18cffbf2fa751bd93@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 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D3811 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:47:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:47:08 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.861cb55ff2a53b2a374bf0d14bc3ba85@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > Can someone produce an example with some actual data constructors? I'm a bit lost as to the actual goal. This is the sort of thing that I want to write: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind data Nat = Z | S Nat type family MkFun (args :: Nat) :: Type where MkFun Z = Type MkFun (S n) = Type -> MkFun n data Foo (args :: Nat) :: MkFun args where MkFoo0 :: Foo Z MkFoo1 :: a -> Foo (S Z) a MkFoo2 :: a -> b -> Foo (S (S Z)) a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:48:57 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.12244edf326c11c87878badcbbf446c9@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by inaki): Replying to [comment:11 ezyang]: > I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful. I just spent a good while trying to do this, but got badly misled by what I think is a different issue: #14075. I think that it is different because that one disappears when I use `-j1`, while the panic when compiling `gi- gio` remains. I will retry to re-minimize without using parallel make (hopefully side-stepping #14075 in this way) when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:54:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:54:07 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.955e84fedb9fa62cea012943522f3f22@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts 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: => QuantifiedContexts Comment: See [wiki:QuantifiecContexts] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:55:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:55:04 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.0451a60b0e118c85b2703d95b757fe04@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedContexts 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: proposal => QuantifiedContexts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:57:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:57:33 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.89216e8adff0c1dc66898795ab83d3bf@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: | QuantifiedContexts 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 RyanGlScott): * keywords: => QuantifiedContexts Comment: I'm adding the `QuantifiedContexts` keyword only because implementing that feature (in the context of `GeneralizedNewtypeDeriving`) would make this feature request obsolete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:57:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:57:56 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.29999b51b9fcf788e75593af6c5b1638@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedContexts 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: Roles => Roles, QuantifiedContexts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 15:58:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 15:58:44 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.915335a42a0aa040146204377bc4adba@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Generics, Resolution: | QuantifiedContexts 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: Generics => Generics, QuantifiedContexts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:01:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:01:21 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.b947e21728dff4481d20b7e54e5a1fe5@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts Operating System: 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 will respond in full in a bit but Replying to [comment:7 RyanGlScott]: > This is important, since the `f` needs to scope over both `x` and `x'`. In your example, the `f` tucked underneath the two occurrences of the `Lens` type synonyms were distinct. Ah yes, the million ISK question is whether GHC can coerce that automatically: or does that enter `ImpredicativeTypes` territory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:12:42 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.f4a8dc343b4e030623ad3f028d8370e8@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: typeable => typeable, UnboxedSums -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:12:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:12:59 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.b42bd4fb7af074cdaddc92aca5432480@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: UnboxedSums 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: => UnboxedSums -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:13:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:13:13 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.6543e71b9edeff3ae6999062f82924b0@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: | TemplateHaskell, UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12478_{1,2,3,4} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448, Wiki Page: | Phab:D2854 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TemplateHaskell => TemplateHaskell, UnboxedSums -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:13:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:13:26 -0000 Subject: [GHC] #12417: API annotations for unboxed sums needs reworking In-Reply-To: <043.00b31e92686f5920efa6f831cd588891@haskell.org> References: <043.00b31e92686f5920efa6f831cd588891@haskell.org> Message-ID: <058.200ebe3679e3bb9c4f5789e6b3029575@haskell.org> #12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => UnboxedSums -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:25:42 -0000 Subject: [GHC] #13748: Variables pretty-printed from -ddump-deriv are not scoped properly In-Reply-To: <050.b0e6834a7632959673c4cff72181e4bd@haskell.org> References: <050.b0e6834a7632959673c4cff72181e4bd@haskell.org> Message-ID: <065.b135d6fa5b087390fa505c4de260e309@haskell.org> #13748: Variables pretty-printed from -ddump-deriv are not scoped properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:27:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:27:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.164144d0313d49c0ffdcd170cd0fc15d@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: QuantifiedContexts => QuantifiedContexts, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:29:09 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.139855caffd8aeb89dfc758c41072dd1@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:29:27 -0000 Subject: [GHC] #13263: cant derive functor on function newtype with unboxed tuple result In-Reply-To: <045.bcb05b59c86f5ba011e078b2a85e6c7f@haskell.org> References: <045.bcb05b59c86f5ba011e078b2a85e6c7f@haskell.org> Message-ID: <060.9514f7676300ca4040cbd941778634d8@haskell.org> #13263: cant derive functor on function newtype with unboxed tuple result -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:29:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:29:40 -0000 Subject: [GHC] #12399: DeriveFunctor fail In-Reply-To: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> References: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> Message-ID: <058.bd33f6775afb5444ab7c5882624d7d23@haskell.org> #12399: DeriveFunctor fail -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:31:16 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.52bdaa38e130a8dd40496d7f4813d14a@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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:D1908 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:32:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:32:00 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.a582b3c913736064161b1724c8127b25@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1797 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:32:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:32:46 -0000 Subject: [GHC] #11837: GHC fails to unify kinds when deriving polykinded typeclass instance for polykinded newtype In-Reply-To: <050.9f83a773e0afc4665e5b1a4fa16ad903@haskell.org> References: <050.9f83a773e0afc4665e5b1a4fa16ad903@haskell.org> Message-ID: <065.a70a663cec58a3b860b550b1d1b464c8@haskell.org> #11837: GHC fails to unify kinds when deriving polykinded typeclass instance for polykinded newtype -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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: #8865, #11833 | Differential Rev(s): Phab:D2117 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:32:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:32:57 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312047=3A_Users_Guide=3A_Generalized?= =?utf-8?q?NewtypeDeriving_derives_=E2=80=9Cinstance_Num_Int_=3D?= =?utf-8?q?=3E_Num_Dollars=E2=80=9D?= In-Reply-To: <051.cf1f9ecab3a9860fedb7bc090a009357@haskell.org> References: <051.cf1f9ecab3a9860fedb7bc090a009357@haskell.org> Message-ID: <066.cd2e4913c596c307ba9cce76a5ce0bda@haskell.org> #12047: Users Guide: GeneralizedNewtypeDeriving derives “instance Num Int => Num Dollars” -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2273 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:33:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:33:08 -0000 Subject: [GHC] #12080: RebindableSyntax breaks deriving Ord In-Reply-To: <046.7713328ee376d4dd3d58a4520e76a2fb@haskell.org> References: <046.7713328ee376d4dd3d58a4520e76a2fb@haskell.org> Message-ID: <061.15c6c282aa7cc4c130d1acfa0ab83d34@haskell.org> #12080: RebindableSyntax breaks deriving Ord -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11396 | Differential Rev(s): Phab:D2247 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:35:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:35:33 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types In-Reply-To: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> References: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> Message-ID: <063.dcb74feb376c07b71ed69b02a51ffe40@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 RyanGlScott): * cc: deriving (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:37:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:37:10 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types In-Reply-To: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> References: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> Message-ID: <063.5064c3505e6e2f3219dd7eabbd57fc74@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving * cc: deriving (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:37:16 -0000 Subject: [GHC] #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance In-Reply-To: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> References: <047.92b5c73d11a6ce75dd9ba55b0b432115@haskell.org> Message-ID: <062.3603a5f640c39eb087e3076da22b28d3@haskell.org> #10561: "deriving (Functor)" on a polykinded type produces ill-kinded instance -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T10561 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:37:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:37:39 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.d7fe391b6a5259cea12fff718aa72321@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T10561 Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Phab:D2097 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:37:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:37:55 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.fc6bef13b2ef9d012620593c27a41ce7@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_run/T10447 Blocked By: | Blocking: Related Tickets: #8678 | Differential Rev(s): Phab:D1031 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:39:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:39:30 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.26b89e3cbea76ade6522404ea1af6c4f@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Generics, Resolution: fixed | 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:D1283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => Generics, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:39:55 -0000 Subject: [GHC] #9444: -ddump-deriv doesn't dump failed newtype-deriving In-Reply-To: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> References: <047.065b5f6e6b688bb61818111621ae3bb4@haskell.org> Message-ID: <062.bdaa2e9ff9aed005e381d488d6d1a5df@haskell.org> #9444: -ddump-deriv doesn't dump failed newtype-deriving -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:40:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:40:12 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.baa99c1ba3362ee72878d28a1b23ca55@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T8631 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:41:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:41:07 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.1501dafbafaa7e05f70a0f933ea592fb@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: GADTs => GADTs, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:41:27 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.f7648022f30338dc3442d93571c6e6b0@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8128 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GADTs, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:41:49 -0000 Subject: [GHC] #7742: StandaloneDeriving on Read fails for GADTs In-Reply-To: <051.7e6acf13cf0dda7d9d5e08d0d4ee0676@haskell.org> References: <051.7e6acf13cf0dda7d9d5e08d0d4ee0676@haskell.org> Message-ID: <066.f3e7a4ace87c88cec5b18ee9342287ef@haskell.org> #7742: StandaloneDeriving on Read fails for GADTs -------------------------------------+------------------------------------- Reporter: hoffstaetter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: invalid | Keywords: deriving Operating System: MacOS X | 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:41:57 -0000 Subject: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion In-Reply-To: <046.ede5a0a4c9b51a0601e5392306d3eb95@haskell.org> References: <046.ede5a0a4c9b51a0601e5392306d3eb95@haskell.org> Message-ID: <061.7a6b8d1d7eab0541be137bcd11e3715e@haskell.org> #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_runt/T7436 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:42:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:42:13 -0000 Subject: [GHC] #4896: Deriving Data does not work for attached code In-Reply-To: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> References: <044.d2e84887ce906663629df5acb6b383eb@haskell.org> Message-ID: <059.212805fa8705eada0a5cdd5458bb3120@haskell.org> #4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T4896 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:43:23 -0000 Subject: [GHC] #3368: Deriving Foldable doesn't work In-Reply-To: <043.07fd00804268a4211b859ee0eb6e08cb@haskell.org> References: <043.07fd00804268a4211b859ee0eb6e08cb@haskell.org> Message-ID: <058.b46d15c9cc9276ad7e308c993c24982d@haskell.org> #3368: Deriving Foldable doesn't work -------------------------------------+------------------------------------- Reporter: cmcq | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:43:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:43:35 -0000 Subject: [GHC] #4019: deriving Ord can produce incorrect and inefficient instances In-Reply-To: <041.298973948e102a278f8085229cb5ae01@haskell.org> References: <041.298973948e102a278f8085229cb5ae01@haskell.org> Message-ID: <056.2d91425b6663280059e19c0115cc7518@haskell.org> #4019: deriving Ord can produce incorrect and inefficient instances -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:43:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:43:44 -0000 Subject: [GHC] #4028: Derived Data instance requires Data instances for unused type parameters In-Reply-To: <044.83be25d9f0ad51a0343fee164efedb42@haskell.org> References: <044.83be25d9f0ad51a0343fee164efedb42@haskell.org> Message-ID: <059.feb82dad09ad3125ebce119534a86595@haskell.org> #4028: Derived Data instance requires Data instances for unused type parameters -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:44:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:44:05 -0000 Subject: [GHC] #4309: Painfully large errors with silly GADT instances In-Reply-To: <046.f741f51d116f744cf341f8797cd67ffe@haskell.org> References: <046.f741f51d116f744cf341f8797cd67ffe@haskell.org> Message-ID: <061.e83dd8a54e19e411024d472c2008f8bc@haskell.org> #4309: Painfully large errors with silly GADT instances -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/drvfail011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:44:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:44:30 -0000 Subject: [GHC] #4529: Deriving Data does not work for attached code In-Reply-To: <044.75eab8250ebf64bdc27cfd2d0f4e5fb6@haskell.org> References: <044.75eab8250ebf64bdc27cfd2d0f4e5fb6@haskell.org> Message-ID: <059.9b50b95370dc55ba8ffe1e2db15ddfb0@haskell.org> #4529: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.1 checker) | Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:44:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:44:44 -0000 Subject: [GHC] #4530: Deriving Data for existentially quantified types In-Reply-To: <044.a665062de6b2dc14ffa37796f86503b6@haskell.org> References: <044.a665062de6b2dc14ffa37796f86503b6@haskell.org> Message-ID: <059.725bb4a72279419e4d965f27e52b6c44@haskell.org> #4530: Deriving Data for existentially quantified types -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 7.1 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:46:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:46:00 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.a2390a70ea17bb1e6e795133caafa4cc@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Generics, | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11509 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => Generics, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:46:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:46:30 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.a0b4af64897557962877bb051af204a4@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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:D3337 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:46:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:46:43 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.9bd4c910e851411a4967cd0fe4a667b5@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Phab:D2692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:46:59 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.9057c424eae313d1c00c328ed73f5510@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Generics, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T13272, | T13272a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => Generics, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:48:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:48:27 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.a33c8b7b0b7e82c414ef678d7a186731@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:48:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:48:35 -0000 Subject: [GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic In-Reply-To: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> References: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> Message-ID: <063.c975a91af9fe190541a4d695a31a7f80@haskell.org> #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #9968 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: DeriveAnyClass => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:49:28 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.a2ecf7cd24c23f123d5db4538f51b314@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:49:51 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.5739c9da2ea84a4a2ecc8ae1dc9df053@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401, #10577 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:50:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:50:05 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.5d1bfb0af0c8ae1beec3cce29e60f260@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1168 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:50:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:50:24 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.559079a66f485725a1a739ee5ae91c75@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Generics, | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_run/T10598_bug Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Generics => Generics, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:52:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:52:13 -0000 Subject: [GHC] #9790: Produce coercion rules for derived Functor instances In-Reply-To: <045.8a527e88bca622461eac96735db65516@haskell.org> References: <045.8a527e88bca622461eac96735db65516@haskell.org> Message-ID: <060.93a48d4115c49e510f207d3816675c1f@haskell.org> #9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: coercion, | deriving 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 RyanGlScott): * keywords: coercion => coercion, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:52:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:52:25 -0000 Subject: [GHC] #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving In-Reply-To: <045.f9bffd180044243f5d493b11cf11851d@haskell.org> References: <045.f9bffd180044243f5d493b11cf11851d@haskell.org> Message-ID: <060.d6ffbb803e29d6f46c65bf7d61d8fba9@haskell.org> #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:52:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:52:36 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising In-Reply-To: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> References: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> Message-ID: <060.9fe215176194b3879175d67598228a53@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving 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 RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:54:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:54:40 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.99407a388e7728d21155df9548971b3a@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.3 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:59:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:59:38 -0000 Subject: [GHC] #13759: Strange error message for deriving Data In-Reply-To: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> References: <044.c89c9d7f67d761ccca1e7e03774533ee@haskell.org> Message-ID: <059.fa9f05935df1d612d5b468563e0ae33a@haskell.org> #13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: duplicate | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 16:59:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 16:59:52 -0000 Subject: [GHC] #3205: Generalized isomorphic deriving In-Reply-To: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> References: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> Message-ID: <057.bbec347993c4375f81f2ec7e9697cbcd@haskell.org> #3205: Generalized isomorphic deriving -------------------------------------+------------------------------------- Reporter: ajd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: language, | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: language => language, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:00:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:00:49 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.de0aaabb20ba219ffc5cbc486eb958dd@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:00 -0000 Subject: [GHC] #5041: Incorrect Read deriving for MagicHash constructors In-Reply-To: <044.9b7a543c5bb57a51cf0f260d7ff16f86@haskell.org> References: <044.9b7a543c5bb57a51cf0f260d7ff16f86@haskell.org> Message-ID: <059.f92a16ac92894ceaa647e8dd18d3b72d@haskell.org> #5041: Incorrect Read deriving for MagicHash constructors -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_run/T5041 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:11 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments In-Reply-To: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> References: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> Message-ID: <066.d0d111fca300967bf29c62e7189cab38@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:19 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.1e90bec0102346f4ad40ff3345956069@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:26 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.b689c4b15889c5e6425257614799f633@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer, | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: newcomer => newcomer, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:38 -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.cd61d869345f0e667df64303ecd9c74b@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): * keywords: FunDeps => FunDeps, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:01:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:01:52 -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.c5e97fd942b0733e66ca4d505c809b25@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:02:44 -0000 Subject: [GHC] #9112: support for deriving Vector/MVector instances In-Reply-To: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> References: <045.090ab3f8e8b58a66c61af9e1c7e40cfe@haskell.org> Message-ID: <060.85c91373ed9020199c0b95f63bfab3a4@haskell.org> #9112: support for deriving Vector/MVector instances -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: deriving, | Roles 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: => deriving, Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:02:52 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.b6e4e76991aba16afe90609f461f0d04@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell, | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: SafeHaskell => SafeHaskell, deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:03:09 -0000 Subject: [GHC] #8263: allow duplicate deriving / standalone deriving In-Reply-To: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> References: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> Message-ID: <060.4e9b921cb6ba87726850508009cf3141@haskell.org> #8263: allow duplicate deriving / standalone deriving -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:05:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:05:33 -0000 Subject: [GHC] #9522: SPECIALISE pragmas for derived instances In-Reply-To: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> References: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> Message-ID: <061.0d736b6f0462065cdf0fbec289a3f3a2@haskell.org> #9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: deriving 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 RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:05:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:05:44 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.9bfdec742cd0508be86f06fa792e26d4@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:06:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:06:31 -0000 Subject: [GHC] #13731: DeriveFunctor and friends don't understand type families In-Reply-To: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> References: <050.1032ec3c6da0c091482ce362aba8c08e@haskell.org> Message-ID: <065.26c9b6ca843931e071ce8ba3421dadf2@haskell.org> #13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded * keywords: => deriving Comment: Requesting feedback from spacekitteh on what is expected here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:15:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:15:22 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.055473f95437f302f1cbf99a3472902f@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ezyang (added) * priority: normal => high * milestone: => 8.4.1 Comment: This is a regression from GHC 8.0.2: {{{ $ /opt/ghc/8.0.2/bin/ghc -j2 -fforce-recomp F O V [1 of 4] Compiling O ( O.hs, O.o ) [2 of 4] Compiling F[boot] ( F.hs-boot, F.o-boot ) [3 of 4] Compiling F ( F.hs, F.o ) F.hs-boot:7:1: error: ‘F.F’ is exported by the hs-boot file, but not exported by the module F.hs:1:1: error: instance O.O F.F -- Defined at F.hs-boot:8:10 is defined in the hs-boot file, but not in the module itself }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:33:22 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.7d73beca1fef514f152b2623890a212b@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:43:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:43:03 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.c7c1440deb46ab4f4fcff893a9d13397@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.2 Comment: In that case let's perhaps try fixing this for 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:45:48 -0000 Subject: [GHC] #14058: Cannot bundle pattern synonym with exported data family In-Reply-To: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> References: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> Message-ID: <065.8bcb5b462e92fc933b944bc11a10fab9@haskell.org> #14058: Cannot bundle pattern synonym with exported data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T14058 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3808 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => patsyn/should_compile/T14058 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:46:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:46:41 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.9f385138f45a809c1eae20a7227f9f8f@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | unboxedsums/T14051 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => unboxedsums/T14051 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 17:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 17:56:20 -0000 Subject: [GHC] #14076: cons operator for list give weird output Message-ID: <046.32bcd5941bed925100f2777863df57eb@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: cons(:) | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on typing the following command in ghci\\ :t 1:2\\ I get the output\\ (Num [a], Num a) => [a]\\ While running the same on char like follows, gives me an error:\\ :t 'a':'b' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 18:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 18:19:05 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.b81ca05ce2a6495fbf2791d9b255459a@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > Do you agree this is a bug? I certainly do. In the bowels of `TcDeriv`, we check that `newTyConEtadRhs` (the eta-reduced representation type) can accommodate the number of arguments from the instance we're deriving. But after doing some `pprTrace` scavenging, I discovered that the `newTyConEtadRhs` for `newtype instance T Int :: Type -> Type` is {{{#!hs ([a_a1vc], IO a_a1vc) }}} Whereas for `newtype instance T Int a :: Type`, it's: {{{#!hs ([], IO) }}} Something fishy is going on. The result of `newTyConEtadRhs` is ultimately being created in `mkNewTyConRhs`, which computes the eta-reduced type variables by checking one-by-one if a tycon tyvar matches the tyvar in the representation type in the corresponding position (see [https://git.haskell.org/ghc.git/blob/c13720c8c6047844f659ad4ce684946b80c99bee:/compiler/iface/BuildTyCl.hs#l89 eta_reduce]). My guess is that this `a_a1vc` tyvar from the representation type doesn't match the corresponding tyvar from `newtype instance T Int :: Type -> Type` (what //would// the corresponding tyvar be, anyway?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 19:05:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 19:05:19 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.cae8451dfcb61aba7ae01a651182ff18@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): Replying to [comment:7 bgamari]: > > Notice that line `--with-ld=...` above, if you installed gcc48 from ports, then it's configured with `--with-ld=/usr/local/bin/ld`. > > Sure, but my understanding is that `-fuse-ld=gold` (which I have confirmed does get passed to `gcc`) should override this default. > Yes, that's what I thought, too.\\ My experience was, `ld` was called instead of `ld.gold`. I'll make further sure of that later.\\ Could you please also confirm that `ld.gold` do get called? > > Since it's an unofficial build, I am not sure if I could use it in production, especial after seeing some test failures. (I am fairly new to GHC building & testing) > > For better or worse this looks relatively "normal" for a FreeBSD build, > > ''... ...'' Thank you very much for the detailed reply to the test results. Again, I'll tweak, build & test later, and keep an eye on those tickets. If there's anything I can help, please count me in. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 19:24:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 19:24:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.f285d02dc5f88a22cb519143040a2abd@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 RyanGlScott): GHC can "coerce" that just fine (roles notwithstanding) if you do it the way `GeneralizedNewtypeDeriving` generates code (pretend I'm using `coerce` instead of `unsafeCoerce`): {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Unsafe.Coerce type Lens s a = forall f. Functor f => (a -> f a) -> (s -> f s) class X f where x :: Lens (f a) a newtype WrappedX f a = WrapX (f a) instance X t => X (WrappedX t) where x = unsafeCoerce @(forall a. Lens (t a) a) @(forall a. Lens (WrappedX t a) a) x }}} I put "coerce" in quotes because we're not actually coercing the `f`. Rather, the two occurrences of `f` tucked underneath the `Lens`es get unified. But you were writing this instance in a somewhat unorthodox way where you manually applied `@t` and `@a` to `x`, but neglected `f` (`f` isn't in scope the way you wrote it, but it's hiding underneath the `Lens`). Because of this, GHC was unable to conclude that the `f` in `x'` and the `f` in the instance signature were the same. Happily, writing instances the way `GeneralizedNewtypeDeriving` does (by visibly applying the full type signatures to `coerce`) doesn't suffer from this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 19:50:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 19:50:37 -0000 Subject: [GHC] #14077: libmingw32.a: Not x86_64 PEi386 Message-ID: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> #14077: libmingw32.a: Not x86_64 PEi386 -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After a fresh installation of the Haskell Platform (on Windows), I received the following error: {{{ >ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.exe: D:/MinGW/bin/../lib/libmingw32.a: Not x86_64 PEi386 ghc.exe: internal error: loadArchive: error whilst reading `D:/MinGW/bin/../lib/libmingw32.a' (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} Invoking GHC will instead error with a bunch of GCC error messages related to standard C library headers (multiple definitions of {{{time_t}}}, etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 20:35:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 20:35:06 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.f872f86f63bbb3b8b766365b4fe326b5@haskell.org> #14057: Upstream Alpine Linux distribution patches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: | -------------------------------------+------------------------------------- Comment (by tuncer): @bgamari, I've forward-ported the ACK'ed patches and put them in https://github.com/ghc/ghc/pull/53 because I didn't know enough arcanist/phab to preserve authorship and avoid a cumulative single diff, and I wanted this to get out sooner than later. I used Joachim as the git- author where I was certain and it's possible that the last two patches can be attributed to Joachim as well, but without digging in Debian's repos and trackers I couldn't say that with certainty. If that's the case, I can rewrite the commits, or feel free to do it when you merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 21:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 21:47:32 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.747e90d80d12cd0876fd8eb4e497ed83@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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 patrickdoc): Things are mostly working now, but a question has arisen. How do we want to categorize the flags? We could just have them grouped by source file (inflexible but simple). Alternatively, we could add an additional option to the flag declaration that chooses the category (flexible but requires specifying where every single flag should go). I could even make it an optional override deal where it is put under source file by default, but you can choose another if you want. I believe the current system is mostly source file based, but not entirely. I'm hesistant to add a 4th field to the declaration, so I thought I would ask if this is something worth supporting or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 22:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 22:47:26 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.274972d4963254bbba0dedb3deb43e7b@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => hs-boot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 1 23:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Aug 2017 23:19:33 -0000 Subject: [GHC] #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" In-Reply-To: <044.3cef4744462e3ff17df5a112d19c05bf@haskell.org> References: <044.3cef4744462e3ff17df5a112d19c05bf@haskell.org> Message-ID: <059.37294396d80e001237845476948022da@haskell.org> #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: rcook | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Backpack 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): * owner: (none) => ezyang Comment: Yeah, looks like we can just add some extra checking for this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 01:44:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 01:44:31 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.88eab3afffb401f0396da763ad2e0ba0@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- 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: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Could you elaborate on comment:4? As in, give a program that would benefit from this treatment (inventing syntax as you go). I think `(=>)` should have kind `Constraint -> TYPE r -> Type`, and that's it. Yes, in class and instance heads, the symbol `=>` appears between two types of kind `Constraint`, but that's not properly a use of the `(=>)` operator; it's just a piece of concrete syntax. To clarify my comment:3, I do think this is a possible direction of future travel and would make an appropriate ghc-proposal. I'm not yet convinced about the idea, but my reluctance is based in personal preference/taste, not technical grounds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 03:15:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 03:15:51 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.2a0766c82b3476fc2e5929d8b1a78332@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: invalid | Keywords: cons(:) Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This looks like correct behavior to me. Recall that numbers in Haskell are overloaded, meaning that the type of a number `1` is `Num a => a`. Your initial expression conses one number onto another -- thus both the element and the list type must be in the `Num` type class. Please reopen if you see a flaw here somewhere, and thanks for posting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 03:41:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 03:41:14 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.f814d2f377faa54952060ff1febdd664@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): In parallel mode I see: {{{ Re-typechecking loop: [F, F] compile: input file F.hs *** Checking old interface for F (use -ddump-hi-diffs for more details): [3 of 4] Compiling F ( F.hs, F.o ) }}} which is wrong wrong wrong; the retypecheck loop MUST NOT contain F (compare with non-parallel output; nothing needs to get retypechecked before we do F). So this is definitely a parallel specific bug. Workaround should be to not use parallel compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 04:52:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 04:52:32 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.3d7f318e5e2314c17b177d211fb7171e@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Phab:D3815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3815 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 06:22:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 06:22:35 -0000 Subject: [GHC] #14071: Porting GHC to another function programming language. (was: Porting GHC to Scheme without side-effecting) In-Reply-To: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> References: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> Message-ID: <059.91e210d32dce9ff2efd8dbaf23b4666b@haskell.org> #14071: Porting GHC to another function programming language. -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by zaoqi): * status: infoneeded => new Old description: New description: For example: Scheme -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 06:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 06:27:54 -0000 Subject: [GHC] #14071: Porting GHC to another function programming language. In-Reply-To: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> References: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> Message-ID: <059.5cf8a5059da28a11f70f44e9aa9e3b9d@haskell.org> #14071: Porting GHC to another function programming language. -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zaoqi: Old description: > For example: Scheme New description: For example: Scheme Scheme is easier to implement interpreters (eg relational interpreter) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 06:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 06:42:51 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.eeb00828c4676209a4a1b112d558eb65@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): It appears that the absurd number of coercions is present in 7.10 as well as 8.0. So we'll need to look at something else to find the perf difference between those versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 07:24:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 07:24:11 -0000 Subject: [GHC] #14077: libmingw32.a: Not x86_64 PEi386 In-Reply-To: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> References: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> Message-ID: <063.e0db3a39ad255c8309bf5a851d4c6bb0@haskell.org> #14077: libmingw32.a: Not x86_64 PEi386 -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): `ghc.exe: D:/MinGW/bin/../lib/libmingw32.a: Not x86_64 PEi386` This path doesn't look like it's the one bundled with Platform. This looks like you have a 32-bit MinGW install on your PATH, which makes findFiles return that `libmingw32.a` instead of the ones bundled with GHC. It's even more suspicious that calling GHC fails with GCC errors about standard headers... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 09:36:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 09:36:20 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.5647a39d81fa804b7a3fe7adff3e797a@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: cons(:) 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 vanto): * status: closed => new * resolution: invalid => Comment: Reply to [[span(style=color: #FF0000, goldfire )]]:\\ you have to write {{{:t 'a':'b':[]}}}\\ reply {{{'a':'b':[] :: [Char]}}}\\\\ otherwise {{{:t 1:2:[]}}}\\ reply {{{1:2:[] :: Num a => [a]}}}\\\\ That's right, it sounds weird. I'm reopening this ticket so you can think a little better about the problem, goldfire.\\ Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 10:22:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 10:22:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.6a34a520c1d931b40b74209463a3b3fb@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 Iceland_jack): Replying to [comment:7 RyanGlScott]: > My hunch is that just about every use case for this proposed `unsafe newtype` deriving strategy would be subsumed by the ability to have quantified contexts involving `Coercible`. That's excellent and I hope that is indeed the case. A choice between `forall a. Coercible (m (M m a)) (m (m a))` and `forall a b. Coercible a b => Coercible (m a) (m b)` in the context is also interesting and makes me wonder if they differ in that example ---- Replying to [comment:11 RyanGlScott]: > Happily, writing instances the way `GeneralizedNewtypeDeriving` .. doesn't suffer from this problem. ah! So this means we can also derive optic methods once `QuantifiedContexts` lands and (possibly / hopefully) that we can derive everything derivable? That would be huge for me and I would be fine with closing this ticket It does require `ImpredicativeTypes` written in the Haskell surface language, wasn't that removed in 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 10:28:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 10:28:28 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.0272ee7f6cf4fb8ba6d26bab0ce43af2@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: cons(:) Operating System: 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): This is expected, someone could define a `Num` instance for lists in a separate module {{{#!hs instance Num a => Num [a] where fromInteger :: Integer -> [a] fromInteger i = [fromInteger] (+) :: [a] -> [a] -> [a] (+) = liftA2 (+) -- .. }}} at which point your expression reduces to `[1,2]` {{{ >> :t 1 : 2 1 : 2 :: Num a => [a] >> 1 : 2 [1,2] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 10:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 10:46:59 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.5d39db7ad2cf8a5fe808a860af3aaf6f@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I found it. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 12:55:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 12:55:56 -0000 Subject: [GHC] #14077: libmingw32.a: Not x86_64 PEi386 In-Reply-To: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> References: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> Message-ID: <063.424f97a87173853358ee85a038d6fa24@haskell.org> #14077: libmingw32.a: Not x86_64 PEi386 -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YoYoYonnY): Is there a way to have Haskell ignore my environment variables and my MinGW installation, then, and if not, shouldn't there be? Unfortunately, installing Haskell Platform for 32 bits doesn't work, and neither would I prefer to do so. Haskell ships with a different version of GCC, for starters. I might look into MinGW-w64 but from my experience, it's not nearly as easy to install as MinGW is. Removing the following from my environment variables ''does'' makes Haskell work: {{{ LIBRARY_PATH=D:\MinGW\bin;%LIBRARY_PATH% INCLUDE_PATH=D:\MinGW\include;%INCLUDE_PATH% }}} However, it makes other programs fail (to compile, but also to run). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 13:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 13:50:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.696261fe98e0bef19a3f6736e3f579bf@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 RyanGlScott): Replying to [comment:12 Iceland_jack]: > ah! So this means we can also derive optic methods once `QuantifiedContexts` lands I'm not sure what's special about "optic methods", but yes, I'm pretty sure `QuantifiedContexts` should let us be able to use `GeneralizedNewtypeDeriving` in any situation where we need to `coerce` underneath a higher-kinded type parameter (like the `f` in `Lens (f a) a`). > and (possibly / hopefully) that we can derive everything derivable? I mean, saying that you can derive everything that is derivable is a bit of a tautology. But I think the answer to that question is yes :) > It does require `ImpredicativeTypes` written in the Haskell surface language, wasn't that removed in 8.2? Alas, `ImpredicativeTypes` hasn't been removed yet. Simon laid out a proposal for doing so, while still preserving the ability to use `TypeApplications` to instantiate polytypes (as in `coerce @(forall a. Lens (t a) a)`) [https://mail.haskell.org/pipermail/ghc- devs/2016-September/012824.html here], but no one has drafted that up into a concrete GHC proposal yet. I'd do this myself, except I'm far too unfamiliar with the typechecker details to come up with a comprehensive document explaining how this change would work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 13:53:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 13:53:07 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.2a4822e4f7f8d7ec44e82c486b1576b8@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Keep walking down the path in comment:2. That looks like a promising direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 14:24:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 14:24:26 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.eb083c604294b47e09adbfed7b0d1ce5@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 Iceland_jack): Replying to [comment:13 RyanGlScott]: > I'm pretty sure `QuantifiedContexts` should let us be able to use `GeneralizedNewtypeDeriving` in any situation where we need to `coerce` underneath a higher-kinded type parameter (like the `f` in `Lens (f a) a`). Okay great > I mean, saying that you can derive everything that is derivable is a bit of a tautology. It was a lazy question, I was wondering if there is anything GNDerivable in theory outside of GHC's reach even given quantified constraints (and your hunch).. Just as `join` is 'derivable' but is not derivable currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 14:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 14:55:02 -0000 Subject: [GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes In-Reply-To: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> References: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> Message-ID: <065.f6a947831709083195458cd6d8ae6495@haskell.org> #13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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: #4028 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 15:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 15:21:41 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.53f5ac157509cb242ec071a0913a2219@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 RyanGlScott): Replying to [comment:14 Iceland_jack]: > I was wondering if there is anything GNDerivable in theory that would be outside of GHC's reach even given quantified constraints (and your hunch).. Just as `join` is 'derivable' but is not derivable currently. In theory, //everything// is GNDable - after all, `GeneralizedNewtypeDeriving` is just a glorified `unsafeCoerce` hack. The real question is if something is GNDable //and// type-safe, but beyond GHC's reach. The only cases that I'm aware of where this happens involves roles, so if you find other scenarios where `GeneralizedNewtypeDeriving` emits code that doesn't typecheck, file another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 15:21:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 15:21:48 -0000 Subject: [GHC] #14077: libmingw32.a: Not x86_64 PEi386 In-Reply-To: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> References: <048.f341e85fdcb22123cc5c0b2bf9b78026@haskell.org> Message-ID: <063.55cbf0a3765ab6f63a0bb615f60db73d@haskell.org> #14077: libmingw32.a: Not x86_64 PEi386 -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: The compiler will only do what you tell it to. As such it follows the standard search path to find dependencies. You're globally modifying your library directories and so telling it to look there, it's doing just that. I believe platform also provides an msys2 shell, you can configure that not to inherit your environment values or remove them in your bash profile. You can try reporting this to https://github.com/haskell/haskell-platform but I can't speak for them whether this is a bug or not. They likely don't want to modify your global environment by default in a heavy handed way. But this is just a configuration issue. Setting `LIBRARY_PATH` will affect all GCC's on the machine if you set it globally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 15:49:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 15:49:23 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.c6cc551a7a03b120038ae5a5f4f9fbd9@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: invalid | Keywords: cons(:) 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: => invalid Comment: > I'm reopening this ticket so you can think a little better about the problem, goldfire. There is, in general, no need to tell goldfire to think better. He already thinks frighteningly goo. Please, vanto, give the developers of GHC the benefit of doubt that they know what they are talking about, and what the appropriate status of a bug is (unless you are very sure that they made a mistake, which is of course possible. In that case point out their mistake in a friendly manner, and let them change the status back if they are indeed wrong). Anyways, GHC is doing everything right here (and it’s not GHC’s fault if Haskell can be a bit confusing sometimes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:02:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:02:58 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi Message-ID: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit. However, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused. This proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely. Reporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump- json` and `:set -ddump-json`. Sorry if it was not warranted. == Steps to reproduce `cmd>` is the shell prompt. {{{#!hs cmd> ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 cmd> type tmp.hs main = print 2 + 2 cmd> ghci -ddump-json tmp.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [] cmd> ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -ddump-json Prelude> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [ {"span": {"file": "tmp.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 19},"doc": "\u2022 No instance for (Num (IO ())) arising from a use of \u2018+\u2019\n\u2022 In the expression: print 2 + 2\n In an equation for \u2018main\u2019: main = print 2 + 2","severity": "SevError","reason": null}, {"span": null,"doc": "[1 of 1] Compiling Main ( tmp.hs, interpreted )","severity": "SevOutput","reason": null}] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:03:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:03:43 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.a49017d9baa973698dbe3a6a3b346c6b@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): On an unrelated note, the output seems reversed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:13:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:13:54 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.88b00f4ebb3bc8f78ab1c41767175243@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I ran out of time, got stuck upgrading to GHC 8 which is now required... Here is the patch: Ryan, would you like to validate and commit? {{{ simonpj at cam-05-unx:~/code/HEAD$ git show 143f08a3 commit 143f08a32b80f7f80d77b518ce207a1051368b9e Author: Simon Peyton Jones Date: Wed Aug 2 15:57:21 2017 +0100 Get the roles right for newtype instances This was a simple slip, that gave rise to the bug reported in comment:13 of Trac #14045. We were supplying roles to mkAlgTyCon that didn't match the tyvars. diff --git a/compiler/typecheck/TcInstDcls.hs b/compiler/typecheck/TcInstDcls.hs index fe513f4..58d4506 100644 --- a/compiler/typecheck/TcInstDcls.hs +++ b/compiler/typecheck/TcInstDcls.hs @@ -695,7 +695,7 @@ tcDataFamInstDecl mb_clsinfo -- the end of Note [Data type families] in TyCon rep_tc = mkAlgTyCon rep_tc_name ty_binders liftedTypeKind - (map (const Nominal) full_tvs) + (map (const Nominal) ty_binders) (fmap unLoc cType) stupid_theta tc_rhs parent gadt_syntax diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index b81192f..dcc134c 100644 --- a/compiler/types/Type.hs +++ b/compiler/types/Type.hs @@ -1315,8 +1315,12 @@ mkLamType v ty mkLamTypes vs ty = foldr mkLamType ty vs --- | Given a list of type-level vars and a result type, makes TyBinders, preferring --- anonymous binders if the variable is, in fact, not dependent. +-- | Given a list of type-level vars and a result kind, +-- makes TyBinders, preferring anonymous binders +-- if the variable is, in fact, not dependent. +-- e.g. mkTyConBindersPreferAnon [(k:*),(b:k),(c:k)] (k->k) +-- We want (k:*) Named, (a;k) Anon, (c:k) Anon +-- -- All binders are /visible/. mkTyConBindersPreferAnon :: [TyVar] -> Type -> [TyConBinder] mkTyConBindersPreferAnon vars inner_ty = fst (go vars) diff --git a/testsuite/tests/deriving/should_compile/T14045.hs b/testsuite/tests/deriving/should_compile/T14045.hs new file mode 100644 index 0000000..d721a3d --- /dev/null +++ b/testsuite/tests/deriving/should_compile/T14045.hs @@ -0,0 +1,13 @@ +{-# LANGUAGE TypeFamilies, KindSignatures, GADTs, GeneralizedNewtypeDeriving #-} + +module T14045 where + +import Data.Kind ( Type ) + +data family T a b :: Type + +-- newtype instance T Int d = MkT (IO d) + +newtype instance T Int :: Type -> Type where + MkT :: IO d -> T Int d + deriving( Monad, Applicative, Functor ) diff --git a/testsuite/tests/deriving/should_compile/all.T b/testsuite/tests/deriving/should_compile/all.T index 0025d25..10e2e60 100644 --- a/testsuite/tests/deriving/should_compile/all.T +++ b/testsuite/tests/deriving/should_compile/all.T @@ -94,3 +94,4 @@ test('drv-phantom', [normalise_errmsg_fun(just_the_deriving)],compile, ['-ddump- test('T13813', normal, compile, ['']) test('T13919', normal, compile, ['']) test('T13998', normal, compile, ['']) +test('T14045', normal, compile, ['']) }}} Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:14:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:14:34 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.5154cf2e5d0d4ac5d5e79ac3b78c476d@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: #13267 | Differential Rev(s): Phab:D3817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3817 Comment: I've submitted Phab:D3817 to remove `Typeable{1..7}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:33:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:33:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.89adc0a0fa6c232fc6c8c52e16bf40b6@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 Iceland_jack): Replying to [comment:15 RyanGlScott]: > The real question is if something is GNDable //and// type-safe, but beyond GHC's reach. That's what I was trying to get at, thanks for the explanation Ryan I feel very positive about this. Should the ticket be closed or kept open until we have `QuantifiedContexts`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:35:56 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.7b73a3682c8f336de73c0377e8ad2a23@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 RyanGlScott): Replying to [comment:16 Iceland_jack]: > Should the ticket be closed or kept open until we have `QuantifiedContexts`? That's up to you. At some point (be it now or after `QuantifiedContexts` is a thing) I'd like to have a ticket for modifying `GeneralizedNewtypeDeriving` to infer quantified `Coercible` constraints. I'd be fine with either making this the ticket for that feature, or for closing this in favor of a different one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 16:48:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 16:48:56 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec Message-ID: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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 code: {{{ {-# LANGUAGE BangPatterns #-} module NoCPR (e) where e :: (Int, Int) -> Int -> Int -> (Int, Int) e x y n = je x y where je !x y | y > 0 = x | otherwise = je x (y + n) }}} (which is adapted from #5949). We get this Core: {{{ -- RHS size: {terms: 38, types: 27, coercions: 0, joins: 1/1} e :: (Int, Int) -> Int -> Int -> (Int, Int) [GblId, Arity=3, Caf=NoCafRefs, Str=m, Unf=OtherCon []] e = \ (x [Occ=Once!] :: (Int, Int)) (y [Occ=Once!] :: Int) (n [Occ=OnceL!] :: Int) -> case x of { (ww1 [Occ=Once], ww2 [Occ=Once]) -> case y of { I# ww4 [Occ=Once] -> joinrec { $wje [InlPrag=[0], Occ=LoopBreakerT[3]] :: Int -> Int -> Int# -> (Int, Int) [LclId[JoinId(3)], Arity=3, Str=m, Unf=OtherCon []] $wje (ww5 [Occ=Once*] :: Int) (ww6 [Occ=Once*] :: Int) (ww7 :: Int#) = case ># ww7 0# of { __DEFAULT -> case n of { I# y1 [Occ=Once] -> case +# ww7 y1 of sat { __DEFAULT -> jump $wje ww5 ww6 sat } }; 1# -> (ww5, ww6) }; } in jump $wje ww1 ww2 ww4 } } }}} Why is there no CPR happening for `e`? In fact, why is there no unboxing happening – it was for the following similar code: {{{ e :: (Int, Int) -> Int -> (Int, Int) e x y = x `seq` if y > 10 then x else e x (y + 1) }}} (This is a spin-off of the dicussion at https://phabricator.haskell.org/D3811#107708). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:02:31 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.1fd610b3a67ba25add7c9ead264ed108@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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 bgamari): Adding a category field sounds like the right solution. I'm not terribly worried about the field count but being able to specify a file-wide default would make this nicer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:02:55 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.ebc658ebd77522b57bd88ae6652bc2bf@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"d74983ef0c4a5b47a53d2821f8be9ebbf86e9257/ghc" d74983ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d74983ef0c4a5b47a53d2821f8be9ebbf86e9257" Get the roles right for newtype instances This was a simple slip, that gave rise to the bug reported in comment:13 of Trac #14045. We were supplying roles to mkAlgTyCon that didn't match the tyvars. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:04:45 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) Message-ID: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13803, #13981 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following set of files: {{{#!hs -- A.hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} module A (AI(..)) where import GHC.Exts (Constraint) class AI (info :: *) where type S info :: * -> Constraint }}} {{{#!hs -- C.hs module C () where import {-# SOURCE #-} qualified OC as OC import {-# SOURCE #-} qualified OV as OV }}} {{{#!hs -- IF.hs module IF where import qualified C as C import {-# SOURCE #-} qualified OF as OF class IsF o }}} {{{#!hs -- IF.hs-boot module IF where class IsF o }}} {{{#!hs -- OC.hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE EmptyDataDecls #-} module OC () where import A (AI(..)) data I instance AI I where type S I = (~) () }}} {{{#!hs -- OC.hs-boot module OC where }}} {{{#!hs -- OF.hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE EmptyDataDecls #-} module OF () where import A (AI(..)) import {-# SOURCE #-} qualified IF as IF data P instance AI P where type S P = IF.IsF }}} {{{#!hs -- OF.hs-boot module OF where }}} {{{#!hs -- OV.hs module OV () where }}} {{{#!hs -- OV.hs-boot module OV where }}} This works with `ghc-8.0.2` and earlier versions, but fails with `ghc-8.2.1`. When I run `ghc IF` for `8.2.1` I get {{{ [ 1 of 10] Compiling A ( A.hs, A.o ) [ 2 of 10] Compiling IF[boot] ( IF.hs-boot, IF.o-boot ) [ 3 of 10] Compiling OC[boot] ( OC.hs-boot, OC.o-boot ) [ 4 of 10] Compiling OC ( OC.hs, OC.o ) [ 5 of 10] Compiling OF[boot] ( OF.hs-boot, OF.o-boot ) [ 6 of 10] Compiling OF ( OF.hs, OF.o ) [ 7 of 10] Compiling OV[boot] ( OV.hs-boot, OV.o-boot ) [ 8 of 10] Compiling C ( C.hs, C.o ) [ 9 of 10] Compiling IF ( IF.hs, IF.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.1 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 IsF which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find IsF 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} For context, this is a minimal testcase of the panic reported in #13803 for `gi-gio`, which persists after fixing the panic in the minimal testcase in ticket:13803#comment:9. (It seems like the original code was hitting more than one issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:04:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:04:55 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.cba4c2414e9d991b462facb190d67cf4@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a, | deriving/should_compile/T14045b Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: indexed-types/should_compile/T14045, indexed- types/should_fail/T14045a => indexed-types/should_compile/T14045, indexed- types/should_fail/T14045a, deriving/should_compile/T14045b * resolution: => fixed Comment: Done. Thanks, Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:06:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:06:08 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.1c6f7b25b1da8d89595b93da3eedf84d@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by inaki): OK, I managed to minimize the problem, it seems to be indeed related to type families. I have filed a separate issue, but perhaps it is the same thing as in this one: #14080. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:07:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:07:10 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.82b0bdd9298123b2972fac154b671446@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ezyang (added) * priority: normal => high * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 17:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 17:07:54 -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.ea48dfcfa06a913b0727de1cf5fdac2a@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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 18:48:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 18:48:37 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour (was: typechecker tests T13594 T13822 tc269 failing in devel2 flavour) In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.b1cb6ef4c5da82c136fb724afdb212f2@haskell.org> #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The tests T13594 T13822 tc269 are failing for me with > BuildFlavour=devel2. They pass with BuildFlavour=validate. > > I have had a brief look to see if I could fix, but this is beyond my > current capabilities. > > There is a comment in tc269.hs saying that it doesn't typecheck, however > that looks to be out of date? > > test output pasted below: > {{{ > =====> tc269(normal) 1 of 3 [0, 0, 0] > cd "./typecheck/should_compile/tc269.run" && "/home/doug/ghc- > dev/devel2/inplace/bin/ghc-stage2" -c tc269.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 -fno-warn-incomplete-patterns > Compile failed (exit code 1) errors were: > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.3.20170723 for x86_64-unknown-linux): > ASSERT failed! > in_scope InScope {k_aSm} > tenv [aRJ :-> k_aSm[sk:2]] > tenvFVs [aSg :-> k_aSg[tau:1], aSm :-> k_aSm[sk:2]] > cenv [] > cenvFVs [] > tys [k_aRJ[sk:1] -> *] > cos [] > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in > ghc:Outputable > assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in > ghc:TyCoRep > checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in > ghc:TyCoRep > substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in > ghc:TcCanonical > 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/utils/Outputable.hs:1186:5 in > ghc:Outputable > assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in > ghc:TyCoRep > checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in > ghc:TyCoRep > substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in > ghc:TcCanonical > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *** unexpected failure for tc269(normal) > =====> T13594(normal) 2 of 3 [0, 1, 0] > cd "./typecheck/should_compile/T13594.run" && "/home/doug/ghc- > dev/devel2/inplace/bin/ghc-stage2" -c T13594.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 -fno-warn-incomplete-patterns > Compile failed (exit code 1) errors were: > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.3.20170723 for x86_64-unknown-linux): > ASSERT failed! > {$trModule = Module (TrNameS "main"#) (TrNameS "Bug"#), > !x_a1o5 = (1, 2)} > [x] > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in > ghc:Outputable > assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in > ghc:DsBinds > 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/utils/Outputable.hs:1186:5 in > ghc:Outputable > assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in > ghc:DsBinds > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *** unexpected failure for T13594(normal) > =====> T13822(normal) 3 of 3 [0, 2, 0] > cd "./typecheck/should_compile/T13822.run" && "/home/doug/ghc- > dev/devel2/inplace/bin/ghc-stage2" -c T13822.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 -fno-warn-incomplete-patterns > Compile failed (exit code 1) errors were: > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.3.20170723 for x86_64-unknown-linux): > ASSERT failed! > Bad coercion hole {a1bG}: (I (x_a19g |> Sym (Ty > (Sym cobox))_N) |> > D:R:IK[0]) > (I (x_a19g |> Sym (Ty (Sym cobox))_N) |> > D:R:IK[0]) > nominal > <(I (x_a19g |> Sym (Ty (Sym cobox))_N) |> > D:R:IK[0])>_N > I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) > I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) > nominal > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 > in ghc:TcMType > 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/utils/Outputable.hs:1186:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 > in ghc:TcMType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *** unexpected failure for T13822(normal) > > Unexpected results from: > TEST="T13594 T13822 tc269" > }}} New description: The tests T13594 T13822 tc269 are failing for me with BuildFlavour=devel2. They pass with BuildFlavour=validate. I have had a brief look to see if I could fix, but this is beyond my current capabilities. test output pasted below: {{{ =====> tc269(normal) 1 of 3 [0, 0, 0] cd "./typecheck/should_compile/tc269.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c tc269.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 -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {k_aSm} tenv [aRJ :-> k_aSm[sk:2]] tenvFVs [aSg :-> k_aSg[tau:1], aSm :-> k_aSm[sk:2]] cenv [] cenvFVs [] tys [k_aRJ[sk:1] -> *] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in ghc:TcCanonical 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/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in ghc:TcCanonical Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for tc269(normal) =====> T13594(normal) 2 of 3 [0, 1, 0] cd "./typecheck/should_compile/T13594.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c T13594.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 -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! {$trModule = Module (TrNameS "main"#) (TrNameS "Bug"#), !x_a1o5 = (1, 2)} [x] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in ghc:DsBinds 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/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in ghc:DsBinds Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T13594(normal) =====> T13822(normal) 3 of 3 [0, 2, 0] cd "./typecheck/should_compile/T13822.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c T13822.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 -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! Bad coercion hole {a1bG}: (I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0]) (I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0]) nominal <(I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0])>_N I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) nominal Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 in ghc:TcMType 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/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T13822(normal) Unexpected results from: TEST="T13594 T13822 tc269" Actual stderr output differs from expected: diff -uw "./dependent/should_fail/T13780c.run/T13780c.stderr.normalised" "./dependent/should_fail/T13780c.run/T13780c.comp.stderr.normalised" --- ./dependent/should_fail/T13780c.run/T13780c.stderr.normalised 2017-08-02 18:34:10.711466876 +0000 +++ ./dependent/should_fail/T13780c.run/T13780c.comp.stderr.normalised 2017-08-02 18:34:10.711466876 +0000 @@ -1,12 +1,14 @@ [1 of 2] Compiling T13780b ( T13780b.hs, T13780b.o ) [2 of 2] Compiling T13780c ( T13780c.hs, T13780c.o ) +ghc: panic! (the 'impossible' happened) + (GHC version 8.3.20170802 for x86_64-unknown-linux): + piResultTy + k_a1dY[tau:1] + 'True + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/types/Type.hs:: in :Type + piResultTy, called at compiler/types/Type.hs:: in :Type -T13780c.hs:11:16: - Expected kind ‘Sing _’, but ‘SFalse’ has kind ‘Sing 'False’ - In the third argument of ‘ElimBool’, namely ‘SFalse’ - In the type family declaration for ‘ElimBool’ - -T13780c.hs:12:16: - Expected kind ‘Sing _1’, but ‘STrue’ has kind ‘Sing 'True’ - In the third argument of ‘ElimBool’, namely ‘STrue’ - In the type family declaration for ‘ElimBool’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T13780c(normal) }}} -- Comment (by duog): Rescind my question as to whether the tc269.hs comments are out of date, I read them again and they are clearly not. Add T13780c failure, which is happening on master at commit d74983ef0c4a5b47a53d2821f8be9ebbf86e9257. It seems quite related to me, but I'll move it to another ticket if you would prefer. Note the unhelpful stack trace. I suspect that since this only happens with ASSERTs enabled, and since piResultTy has a HasDebugCallStack constraint, that piResultTy is panicking inside an ASSERT and the HasDebugCallStack machinery is breaking in this case? If you agree, and would expect it to work here, I would be happy to look into fixing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 18:59:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 18:59:58 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.37b5e623859a7fd1adc05299c668229b@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, in this case, this is because `certainlyWillInline` returns `True` for `e`, so `tryWW` will refrain from W/W’ing this function. If I mark it as `NOINLINE` then we get the desired code (note that the join-point has it’s return type changes as well:) {{{ $we [InlPrag=NOINLINE] :: Int -> Int -> Int# -> Int -> (# Int, Int #) [LclId, Arity=4, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=4,unsat_ok=True,boring_ok=True)}] $we = \ (ww :: Int) (ww :: Int) (ww [Dmd=] :: Int#) (w [Dmd=] :: Int) -> joinrec { $wje [InlPrag=[0], Occ=LoopBreaker] :: Int -> Int -> Int# -> (# Int, Int #) [LclId[JoinId(3)], Arity=3, Str=, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=True)}] $wje (ww :: Int) (ww :: Int) (ww [Dmd=] :: Int#) = case ># ww 0# of { __DEFAULT -> case w of { I# y [Dmd=] -> jump $wje ww ww (+# ww y) }; 1# -> (# ww, ww #) }; } in jump $wje ww ww ww }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 19:34:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 19:34:08 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.a1bbc088b20c99d3e22049fc9938b3b4@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I just run into this in our `ghc-8.0.2-facebook` branch (we cut from ghc-8.0 before the revert happened). It reproduces in an interesting way with `haddock` + `DuplicateRecordFields`: {{{ $ cat A.hs Main.hs; haddock A.hs Main.hs {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE DuplicateRecordFields #-} module A where data A = A { func :: Int -> Int } a :: A a = A { func = (*2) } module Main where import A main :: IO () main = print (func a 10) Haddock coverage: 0% ( 0 / 3) in 'A' Missing documentation for: Module header A (A.hs:4) a (A.hs:8) Main.hs:6:15: error: • Can't find interface-file declaration for variable A.$sel:func:A 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 • In the first argument of ‘print’, namely ‘(func a 10)’ In the expression: print (func a 10) In an equation for ‘main’: main = print (func a 10) | 6 | main = print (func a 10) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 19:56:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 19:56:40 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs Message-ID: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs --------------------------------+---------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- I'd like to report pretty severe issue with `runghc` executable from latest `8.2.1` release. Namely, `runghc` does not work at all on x32 Windows - it produces segmentation faults even on hello world program {{{ $ cat HW.hs module HW (main) where main :: IO () main = do putStrLn "Hello, world" $ runghc HW.hs Access violation in generated code when reading 77dbffff }}} I managed to reproduce this issue on 3 mildly different hosts already - two of them were running `Windows 7` and the third one was `Windows Server 2008` or `2012` (I forgot which but can look it up if it's crucial). In all 3 cases I used ghc from `https://downloads.haskell.org/~ghc/8.2.1/ghc-8.2.1-i386-unknown- mingw32.tar.xz`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 20:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 20:44:03 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.b73e0147fcb3f38854f342b4dba24462@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: cons(:) 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 vanto): * status: closed => new * resolution: invalid => Comment: Reply to [[span(style=color: #FF0000, nomeata )]]:\\ '''Well, sorry about that. I apologize for the hassle I gave to some of you'''. But this sentence is just a simple discussion and not a criticism of a GHC developer. And I'm very surprised at your behavior. Goldfire can think better just like me I can also think better and you and everyone can also think better!.\\ '''Where is the wrong in this sentence?'''.\\ I know you work a lot and even you do a good job. But if I want to draw the attention of someone of you I reopen the ticket for a discussion, not to bother you.\\ Here AshHash is right to point this difference. Maybe the error message needs to be improved?\\ '''If you don't want to think better, leave the Committee! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:09:39 -0000 Subject: [GHC] #12397: Support for PDB debug information generation In-Reply-To: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> References: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> Message-ID: <060.8abce3d638878771ce0a1e63230b6f8c@haskell.org> #12397: Support for PDB debug information generation -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Debugging) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Possible implementation in 8.4? This really depends upon whether someone steps up to implement it. If so, sure; I will happily accept a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:18:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:18:34 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.7b1270e3a1806be92205dc5148dc6096@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've noted this on [[Building/Preparation/FreeBSD]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:35:25 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.286e85d9617bd5e3113ac0341a61540f@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * priority: normal => highest * milestone: => 8.2.2 Comment: Thanks for your report. This sounds quite bad indeed. I'll try to have a look soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:35:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:35:50 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.dbcbb63f78d72cf982b6da0d4ed923d5@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:42:19 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.36d0bf85e3ed72ec8b70f80d0040e332@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.0.1 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:D3778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Merged for GHC 8.2.2 as well. I believe we can now close this. Thanks patrickdoc! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 21:44:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 21:44:13 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.97ab58a6a77c7823b1f39b3b308b635b@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: mpickering (added) * milestone: => 8.2.2 Comment: Ccing mpickering who wrote this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:13:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:13:05 -0000 Subject: [GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights" In-Reply-To: <045.57be69db71101b923edaf0af27593704@haskell.org> References: <045.57be69db71101b923edaf0af27593704@haskell.org> Message-ID: <060.03d2d637b9b604bfb6edf57b2c219c26@haskell.org> #13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We are certainly open to better solutions. However, I'll admit I don't have any great ideas at the moment. Knowing whether inlining is fruitful in general is a hard problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:16:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:16:13 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.8696894c5386711a067d39c54ee34a6b@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 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): I don't think we need to bring LLVM into this. It's just a question of how we want to insert tracing output. Doing this in STG to Cmm would be one option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:38:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:38:00 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.cb5e6681a94bacf31c54e88ee62a3a7b@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): When `e` is small we don't to w/w; insteead we inline the function bodily at all call sites. If you make it bigger, thus {{{ {-# NOINLINE dummy #-} dummy x = x e :: (Int, Int) -> Int -> Int -> (Int, Int) e x y n = je x y where je !x y | y > 0 = x | otherwise = je x (dummy y + dummy n) }}} then `e` is big enough, and full w/w happens. Actually it looks fine to me. All the right things are happening. So is ther a bug here at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:42:19 -0000 Subject: [GHC] #14054: Cabal generates ill-typed Paths module when relocatable In-Reply-To: <045.4319866d264e103497bc03abff674a19@haskell.org> References: <045.4319866d264e103497bc03abff674a19@haskell.org> Message-ID: <060.82decba7a382079be856928e3a2c3704@haskell.org> #14054: Cabal generates ill-typed Paths module when relocatable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: Cabal Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Thanks for opening a ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:55:49 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.dac8fb4d42f41aeea34feabf6ce4d8c3@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): I haven't been able to reproduce the segfault yet, but there is a startup issue with the bindist.. A call that's been there since 8.0.2 is failing. But it's gracefully failing for me.. I'll start a build but in the meantime can you perhaps provide a crash dump so I can verify the two issues are related? Instructions on how to are here https://msdn.microsoft.com/en- us/library/windows/desktop/bb787181(v=vs.85).aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 22:57:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 22:57:33 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.5e28cef38d4d1d1cab82351c68e7f7a5@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): Oh and what environment/shell are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 23:18:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 23:18:11 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.d58d33df5d0ea6e13372ade08e885a50@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: invalid | Keywords: cons(:) 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 dibblego): * status: new => closed * resolution: => invalid Comment: Replying to [comment:5 vanto]: Hi vanto, we thought about this a lot and this is the correct behaviour of GHC. If you'd like to discuss why it is correct behaviour, I invite you to IRC where we can think better together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 23:29:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 23:29:19 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.67595944570c46ce5f9870906dc978f5@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Hi! Let's consider the following code (compiled with `-O2`, `mtl` and > `criterion` needed): > > {{{#!hs > module Main where > > import Prelude as > import Criterion.Main > import Control.Monad.State.Strict > import Control.Monad.Identity > > repeatM :: Monad m => m a -> Int -> m () > repeatM f = go where > go 0 = pure () > go i = f >> go (i - 1) > {-# INLINE repeatM #-} > > incState :: MonadState Int m => m () > incState = modify' (1+) ; {-# INLINE incState #-} > > test1, test2 :: Int -> Int > test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState > a >> get)) n ; {-# INLINE test1 #-} > test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get > ; {-# INLINE test2 #-} > > main :: IO () > main = do > defaultMain > [ bgroup "monad transformers overhead" > [ bench "test1" $ nf test1 100000000 > , bench "test2" $ nf test2 100000000 > ] > ] > }}} > > Functions `test1` and `test2` differ only syntactically and this > difference should not affect GHC's inliner, because their implementations > use fully saturated calls. The generated core for `test1` and `test2` is > practically identical (there is an additional alias created for `test1`: > `test1 = lvl1_rhor 'cast' ...`). > > The problem is that `test1` runs **3 times faster** than `test2`. > > As a side note - if we add more state transformers to `test1`, it > optimizes them all away, while `test2` runs slower with each new > transformer applied. New description: Hi! Let's consider the following code (compiled with `-O2`, `mtl` and `criterion` needed): {{{#!hs {-# LANGUAGE FlexibleContexts #-} module Main where import Prelude import Criterion.Main import Control.Monad.State.Strict import Control.Monad.Identity repeatM :: Monad m => m a -> Int -> m () repeatM f = go where go 0 = pure () go i = f >> go (i - 1) {-# INLINE repeatM #-} incState :: MonadState Int m => m () incState = modify' (1+) ; {-# INLINE incState #-} test1, test2 :: Int -> Int test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState a >> get)) n ; {-# INLINE test1 #-} test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get ; {-# INLINE test2 #-} main :: IO () main = do defaultMain [ bgroup "monad transformers overhead" [ bench "test1" $ nf test1 100000000 , bench "test2" $ nf test2 100000000 ] ] }}} Functions `test1` and `test2` differ only syntactically and this difference should not affect GHC's inliner, because their implementations use fully saturated calls. The generated core for `test1` and `test2` is practically identical (there is an additional alias created for `test1`: `test1 = lvl1_rhor 'cast' ...`). The problem is that `test1` runs **3 times faster** than `test2`. As a side note - if we add more state transformers to `test1`, it optimizes them all away, while `test2` runs slower with each new transformer applied. -- Comment (by bgamari): I also can't reproduce this result with 8.2.1, {{{ benchmarking monad transformers overhead/test1 time 412.5 ms (378.3 ms .. 443.0 ms) 0.999 R² (0.997 R² .. 1.000 R²) mean 425.7 ms (418.6 ms .. 430.2 ms) std dev 6.749 ms (0.0 s .. 7.751 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking monad transformers overhead/test2 time 373.2 ms (341.6 ms .. 532.9 ms) 0.970 R² (NaN R² .. 1.000 R²) mean 372.6 ms (351.4 ms .. 392.8 ms) std dev 34.07 ms (0.0 s .. 34.92 ms) variance introduced by outliers: 22% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 2 23:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Aug 2017 23:58:22 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.3243d9b19902180606a38ad5f3762a59@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by bgamari): Sadly I've also been unable to reproduce this as well on Windows 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 01:21:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 01:21:58 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.1c76a5e8ddfd0e19408f7db5526f1a9d@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Yes, that's what I thought, too. > My experience was, ld was called instead of ld.gold. I'll make further sure of that later. > Could you please also confirm that ld.gold do get called? Wow, indeed you are right. The `-fuse-ld=gold` seems to be ignored entirely (determined by passing `-optl-v` to `ghc`.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 01:27:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 01:27:44 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.5cfd1e7dd9d029ddf074e563a20d0b5b@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- 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: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://gist.github.com/Icelandjack/378d0b38e8043d68c8c78c62659cdb3d Gist] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 01:56:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 01:56:34 -0000 Subject: [GHC] #14082: -ddump-json does not escape output properly Message-ID: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> #14082: -ddump-json does not escape output properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 This program {{{#!hs module StringError where q = "string" + "string" }}} Compiled with `-ddump-json`, produces this JSON output: {{{ [ {"span": {"file": "tmp.hs","startLine": 3,"startCol": 5,"endLine": 3,"endCol": 24},"doc": "\u2022 No instance for (Num [Char]) arising f rom a use of \u2018+\u2019\n\u2022 In the expression: "string" + "string"\n In an equation for \u2018q\u2019: q = "string" + "string""," severity": "SevError","reason": null}] }}} It is not valid JSON, because `"string"` occured in a JSON string, but the quotes are not escaped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 02:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 02:24:43 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.9e734c477a5997a3aca07955b406a493@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- 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: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Re comment:6 : I'm not so worried about finding examples of where this would possibly be helpful. I'm interested in full examples showing how this might work, in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 04:22:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 04:22:14 -0000 Subject: [GHC] #14082: -ddump-json does not escape output properly In-Reply-To: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> References: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> Message-ID: <065.52a868a477d13115ce188ba9d2e4b0b8@haskell.org> #14082: -ddump-json does not escape output properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): Looks like https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/utils/Json.hs;884bd21a917f607b5a44e038e06f78d0b765ea63$42 A typo causes `"` to be escaped to `"`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 04:48:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 04:48:21 -0000 Subject: [GHC] #14083: ? Message-ID: <044.25fd060c4f1d487121c29dd02e554eab@haskell.org> #14083: ? -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPABLE #-} (Eq a) => GEq a a where geq = (==) instance {-# OVERLAPPING #-} GEq a b where geq _ _ = False }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq () () :2:1: error: • Overlapping instances for GEq () () arising from a use of ‘geq’ Matching instances: instance [overlapping] [safe] GEq a b -- Defined at GEq.hs:9:30 instance [overlappable] [safe] Eq a => GEq a a -- Defined at GEq.hs:6:31 • In the expression: geq () () In an equation for ‘it’: it = geq () () *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 07:22:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 07:22:31 -0000 Subject: [GHC] #14083: ? In-Reply-To: <044.25fd060c4f1d487121c29dd02e554eab@haskell.org> References: <044.25fd060c4f1d487121c29dd02e554eab@haskell.org> Message-ID: <059.921f859317139f710cc29d6c43274bfb@haskell.org> #14083: ? -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): ? repeat of #14004 (or at least same code) To repeat Ryan's ticket:14004#comment:3 from there >> Your description still isn't very clear. What exactly is the bug here? Try: {{{ instance {-# OVERLAPPING #-} (Eq a) => GEq a a where geq = (==) instance {-# OVERLAPPABLE #-} GEq a b where geq _ _ = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 07:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 07:59:00 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.5b5433a9e0e2491f006f47a9fef6a4bb@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): I can reproduce the issue using following shells: 1. x64 msys 2.0 2. x32 git-bash that's bundled with portable-git 1.9.5 3. Not too old cygwin (sorry, don't have it with me right now) I'll try to provide the dump later since just following instructions in https://blogs.msdn.microsoft.com/chaun/2013/11/12/steps-to-catch-a-simple- crash-dump-of-a-crashing-process/ does not produce any dumps for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 07:59:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 07:59:57 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.21bc1d93c6e19d3261f4dc13fef6c4ac@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: invalid | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): Thought as much, but the error message encouraged me to file a bug report so I did -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 08:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 08:02:35 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.5d59eae88600696a79e60da9167b09ba@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): Does GHC and GHCi work? or do they all segfault? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 08:04:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 08:04:17 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.1eaba0b118cfcc80cd0906353291c317@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: invalid | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No worries! Appreciate the report, I prefer to get it than not and it turning out to be an actual bug :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 08:05:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 08:05:43 -0000 Subject: [GHC] #14082: -ddump-json does not escape quotes properly (was: -ddump-json does not escape output properly) In-Reply-To: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> References: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> Message-ID: <065.8945628c8212c47f0fe7f40c52ecc0d6@haskell.org> #14082: -ddump-json does not escape quotes properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): Changing title to reflect my best guess -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 12:33:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 12:33:58 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi Message-ID: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- * A: you type {{{:set +t}}} then you write {{{1:2}}}, the answer is:\\ {{{ Prelude> :set +t }}} {{{ Prelude> 1:2 :8:1: error: * Non type-variable argument in the constraint: Num [a] (Use FlexibleContexts to permit this) * When checking the inferred type it :: forall a. (Num [a], Num a) => [a] }}} \\ * B: you type {{{:t 1:2}}}, the answer is:\\ {{{ Prelude> :t 1:2 1:2 :: (Num [a], Num a) => [a] }}} \\ There is an obvious bug. Don't answer me that this behavior is correct, please! The two answers should be the same. Either answer A or answer B. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 13:18:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 13:18:00 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.68df71911461ad3b2fea9f9ccf26801b@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => closed * resolution: => invalid Comment: This behavior is correct. It has nothing to do with `:set +t`. B: `:t 1:2` just shows the inferred type for `1:2` A: {{{ Prelude> 1:2 }}} is equivalent to {{{ Prelude> let it = 1:2 }}} which fails to type-check the inferred type for `1:2` if you don't enable FlexibleContexts. Please [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/ refer to the manual] and use [https://mail.haskell.org/mailman/listinfo/beginners this mailing-list] instead of the bug tracker when you don't understand GHC's behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 13:19:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 13:19:02 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.300e64ebbd2be1773ecd28f36b243d20@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): @vanto, I think you'll get better explanations if you post these kind of questions on StackOverflow, or the beginners forum. If the people there tell you to report a bug, then come to Trac. (For comparison, I've been using GHC for over 10 years. I've never felt a need to raise a bug.) Briefly: this behaviour is correct. When you go {{{ Prelude> 1:2 }}} You are asking to evaluate the expression. (As well as give its type.) To evaluate the expression, GHC must figure out its type. Its type is indeed not Haskell2010-conformant: it needs `FlexibleContexts`. Contrariwise, when you go {{{ Prelude> :t ... }}} You are not asking to evaluate the expression. You are merely asking for its type. GHCi is being generous (I'd say) in telling you the type irrespective of whether that type is conformant with current settings/extensions. I see no bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 13:31:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 13:31:32 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument Message-ID: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Function `intToSBigNat#` returns a `PosBN` result when input is < -1, but it should be `NegBN` instead. As a consequence functions like `powModInteger` give incorrect result for small negative numbers: {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > :m GHC.Integer.GMP.Internals > powModInteger (-2) 3 123 8 > (-2)^3 `mod` 123 115 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 14:12:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 14:12:37 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.f831b9324fb57ffd0f7aedbafda71212@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Not sure to what extend there is a bug, but I believe it explains the regressions when we introduce loopification. Let’s start with this code. {{{ je :: (Int, Int) -> Int -> (Int, Int) je !x y | y > 0 = x | otherwise = je x (makeBig y + 1) }}} Without loopification, this stays a top-level recursive bindings. Even if it is small, it is never inlined, so w/w happens, and we get a nice worker, with both tuples unboxed: {{{ $wje :: Int -> Int -> Int# -> (# Int, Int #) }}} This avoid allocation of tuples, which is great. Now, let’s do loopification by hand (the extra `n` is just to avoid floating `je` to the top-level, because we do not support top-level join points: {{{ e :: (Int, Int) -> Int -> Int -> (Int, Int) e x y n = je x y where je !x y | y > 0 = x | otherwise = je x (y + n) }}} Now `e` is small and, by changing from recursive to non-recursive, now inlineable. Therefore w/w refuses to work on `e` and we get no worker for `e`. We do get a worker for the local join point `je`, but because it is a join-point, no CPR happens, and its type is {{{ $wje :: Int -> Int -> Int# -> (Int, Int) }}} As you point out that other changes to `e` (such as making it look big, or marking it `NOINLINE`) avoid this and give it a nice wrapper. But that is a red herring: The code out there _is_ small and _isn’t_ marked `NOINLINE`. Anyways, so we are stuck with an inlineable `e` without a worker. The next question is hence: What happens with it? If we indeed inline `e`, and inline it into a nice context (say, into `case _ of (x,y) -> _`, then case-of-case (and case-of-joinrec) will move this `case` deep into the `letrec`. But (and at this point I am running out of concrete examples. I guess I have to look closer at nofib), what if that does not happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 14:13:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 14:13:32 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.92e6efc596d7705a2d8271688cc64837@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => infoneeded Comment: I can reproduce on 8.2.1, and I cannot reproduce on HEAD. I did test with my fix for #14075 so you may need to apply it (though I also tried with another random HEAD build I had lying around, and it was fine.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 16:36:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 16:36:47 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.9d053afe2cff4f203805cec395723e55@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Reply. Thanks for the answers. Okay, you're right. Mea culpa, mea culpa, mea maxima culpa. Thank you for indicating where to ask questions. Truthfully I thought it was a bug.\\ However something is not right.\\ 1:2 is not a list. Where is the empty list [] ?\\ GHC should not be able to evaluate this expression which is poorly written. And yet it does. It's amazing.\\ It can with numbers but it can not with characters.\\ The ML and Miranda compilers, for example, do not manage to evaluate this kind of poorly written list, as well as with numbers or characters.\\ Intellectually this should be considered a bug.\\ {{{ Here are examples of lists: 1:2:3:[] [1,2,3] 1:2:undefined [1,2,..] 'a':'b':[] ['a','b'] }}} I'm going to open a new bug ticket soon. And that is not a request for information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 17:15:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 17:15:26 -0000 Subject: [GHC] #14086: Empty case does not detect kinds Message-ID: <045.9d1433772cd165bffb28d64041403a96@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, EmptyCase #-} module Silly where import Data.Kind f :: Type -> Int f x = case x of }}} GHC warns {{{ Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ :: * }}} In fact, `Type` is only a type because of `TypeInType`. It has no actual values, so the empty case is exhaustive. To be honest, I kind of wish GHC would give me a warning for doing something so silly as to even give a function an argument of type `Type`, but I imagine that might be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 17:22:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 17:22:10 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.29381a7b7341d05aa5d36b06dfb47f5c@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): @vanto > It can with numbers but it can not with characters. It seems like you don't understand the type of numeric literals in Haskell. Please read https://www.haskell.org/onlinereport/basic.html#sect6.4.1 Then this will make sense: {{{#!hs > :t (:) (:) :: a -> [a] -> [a] > :t 1 1 :: Num t => t > :t (1:) (1:) :: Num a => [a] -> [a] > :t (1:2) (1:2) :: (Num [a], Num a) => [a] }}} > The ML and Miranda compilers, for example, do not manage to evaluate this kind of poorly written list, as well as with numbers or characters. Probably because they aren't compilers for the same language. AFAIK ML compilers don't allow `1` to be used as a Float literal, we have to use `1.` instead. Different trade offs... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 18:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 18:49:34 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.66f06f34b397b062c625ae334bdfd9c4@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): It's pretty strange now that I tried all of them: ghc works, compiled executable of HW.hs works but ghci segfaults with same message as runghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 18:50:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 18:50:35 -0000 Subject: [GHC] #14076: cons operator for list give weird output In-Reply-To: <046.32bcd5941bed925100f2777863df57eb@haskell.org> References: <046.32bcd5941bed925100f2777863df57eb@haskell.org> Message-ID: <061.632aa1658b1bd0d46c99691718c7ad21@haskell.org> #14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: invalid | Keywords: cons(:) Operating System: 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 reopen the ticket for a discussion There is no reason to reopen a ticket, just to have a discussion. The ticket is closed as invalid right now, and we are still having a discussion here. If the discussion comes to a conclusion that there is something to be done, then someone will change the status of the ticket accordingly. > Maybe the error message needs to be improved? Which error message? He was observing {{{ :t 1:2 (Num [a], Num a) => [a] }}} which (rightly) does not produce any error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 18:51:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 18:51:52 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.2453fac1e12a92de9badeaa528278384@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I'm somewhat surprised this doesn't work, given that `Type` expands to `TYPE LiftedRep`, and `TYPE` is itself a datatype with no constructors. Granted, it is a somewhat magical datatype, but perhaps that just means we need to adjust the magicks appropriately for the `EmptyCase` pattern-match exhaustivity checker's purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 19:14:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 19:14:05 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.087ae8f935c93d6bbe991f2dacb10c23@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 19:43:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 19:43:54 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.b1c68ef1dc6308428b7454942ee8e9f8@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): Another update: after updating msys 2.0 the crash disappeared in both `runghc` and `ghci`. Even portable-git's `git-bash` now behaves correctly, which is really puzzling. Apparently it's somehow related to dlls that ghc distribution uses. However, the crash is still there if I use `cmd.exe`: {{{ c:\home>ghc\ghc-8.2.1-x32\bin\ghci.exe -v3 -dcore-lint GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 8.0.1 Using binary package database: C:\home\ghc\ghc-8.2.1-x32\lib\package.conf.d\pack age.cache package flags [] loading package database C:\home\ghc\ghc-8.2.1-x32\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.067 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.051 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 0.857 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.067 megabyte s Access violation in generated code when reading 7736ffff }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 19:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 19:49:28 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.589e46e9d20b396845b02c44d14f0767@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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:D3819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3819 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 19:59:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 19:59:09 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.7ef6acab8e11a843458cb35d30471300@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): I just ran into this issue myself. The main thing I have to add is to note that this issue also affects -fhpc, so whatever solution should take that into account too. I took a look through FlagChecker.hs for other candidates, but didn't see anything else. A simple fix would be for ghci to note that -fhpc or -O are being ignored, but still include them in its flag hash when it does the recompilation check. I didn't notice that suggestion in the discussion above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 20:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 20:49:26 -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.a9831febe89fd2d870dc9a348a6e1c8d@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.4.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 lippling): (I'm not exactly sure if this is the right ticket) I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2).\\\\ The compilation runs smooth, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with an stack overflow error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 21:46:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 21:46:35 -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.a89485f5a85f495f9feceb96f121e68d@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, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Similarly, using a scoped type variable in a type annotation doesn't count as a use: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wunused-foralls #-} module Bug where import Data.Proxy proxy :: forall k (a :: k). Proxy a proxy = Proxy data SomeProxy where SomeProxy :: forall k (a :: k). Proxy a -> SomeProxy someProxy :: forall k (a :: k). SomeProxy someProxy = SomeProxy (proxy :: Proxy a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 21:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 21:52:17 -0000 Subject: [GHC] #14087: Ambiguous record field name destructure on qualified imported modules causes compiler crash Message-ID: <050.343bf6751c38b2e8a702103083ace5c4@haskell.org> #14087: Ambiguous record field name destructure on qualified imported modules causes compiler crash -------------------------------------+------------------------------------- Reporter: philipwhite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I have two extremely simple files which will reproduce this crash. Main.hs: {{{ module Main where import qualified B as B x = 0 main :: IO () main = do let B.T { x = inside } = B.value putStrLn (show inside) }}} B.hs {{{ module B where data T = T { x :: Bool } value :: T value = T { x = True } }}} I did a qualified import of one module into the main module. I tried to destructure a record from this module, but I didn't qualify the record fields in the destructuring expression. The output of the compiler is below: {{{ Building ghcbug-repro-0.1.0.0... Preprocessing executable 'ghcbug-repro' for ghcbug-repro-0.1.0.0... [2 of 2] Compiling Main ( Main.hs, dist/build/ghcbug-repro /ghcbug-repro-tmp/Main.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): translateConPatVec: lookup 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 Aug 3 21:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 21:58:11 -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.28c896b51362132d34697acf9cd208e0@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 RyanGlScott): * keywords: TypeApplications, newcomer => TypeApplications Comment: By the way, at one point I looked into how one might fix this bug, but I didn't get very far. There's chicken-and-egg problem: the `Unused quantified type variable` analysis (and subsequent warning) are done entirely within `bindLHsTyVarBndrs`, which is called from `rnValBindsLHS`. However, to account for uses of type variables from type annotations or visible type applications, we'd need the results of `rnValBindsRHS`, but this must be run //after// `rnValBindsLHS`! This leads me to believe that either: * This `Unused quantified type variable` check shouldn't belong in `bindLHsTyVarBndrs`. * We need to somehow make `bindLHsTyVarBndrs` aware of function RHSes as well for warning purposes. Either way, I don't think is quite a newcomer bug :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 22:02:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 22:02:05 -0000 Subject: [GHC] #14087: Ambiguous record field name destructure on qualified imported modules causes compiler crash In-Reply-To: <050.343bf6751c38b2e8a702103083ace5c4@haskell.org> References: <050.343bf6751c38b2e8a702103083ace5c4@haskell.org> Message-ID: <065.7d534359034bf2823739ba799f092e5f@haskell.org> #14087: Ambiguous record field name destructure on qualified imported modules causes compiler crash -------------------------------------+------------------------------------- Reporter: philipwhite | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: #13644 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13644 Comment: Closing as a duplicate of #13644. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 3 22:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Aug 2017 22:03:12 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.8227a49939d3ed048a8fabfdaf56f509@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13840, #13973 => #13840, #13973, #14087 * milestone: => 8.4.1 Comment: And #14087. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 01:17:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 01:17:48 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.b351cf117c05823b91527031960d2d51@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:3 vanto]: > However something is not right.\\ Chiefly, that you do not understand Haskell's typeclass system and overloading. GHCi is great for 'quick qnd dirty' experimenting; but I note you haven't actually written a program yet. So to head you off from alleging more bugs that are not bugs ... > 1:2 is not a list. Where is the empty list [] ?\\ If you try to put (say) `x = 1:2` in a program, it won't compile. So you can not make any claims about what `1:2` is or is not. What GHCi's `:t 1:2` is telling you is: * if you supply some specific type (call it `a0`); * and you have `instance Num a0` and `instance Num [a0]`; * then you'll have a list type `[a0]`. Note there is no `instance Num a => Num [a]` in the Prelude, but for all GHCi knows, perhaps you're about to load a program that supplies one. Perhaps the reason you're asking for `:t 1:2` is precisely because you're doing that, and you want to check first. It would be really annoying if GHCi didn't play ball. > GHC should not be able to evaluate this expression which is poorly > written. And yet it does. It's amazing.\\ No it doesn't evaluate nothing. `:t` is not evaluating (as I said); it's telling you what you need to supply, in order to evaluate. You've tried putting `1:2` and you got an error message; no evaluating. Even if you `:set -FlexibleContexts`, you'll still get a (different) error message. It'll (probably) talk about `No instance for Show [a0] ...`. That's not a bug; and it's not evaluating. As another example of that, put `x = 1:2:[]` in a program and compile it. Then ask `:t x`. Please do not report that as a bug. You'll be learning about default typing. > It can with numbers but it can not with characters.\\ Who says characters are not `Num`eric? Try this at the prompt: `:t 1 + 'c'`. This is also not a bug. > The ML and Miranda compilers, for example, do not manage to > evaluate this kind of poorly written list, as well as with numbers or characters.\\ Haskell does not evaluate this kind of poorly written list. (Unless you supply extra instances over what's in the Prelude.) Same same. > Intellectually this should be considered a bug.\\ That's a comment on your intellect. You could go and find a copy of Hugs. That represents Haskell of ~10 years ago. You'll see exactly the same behaviour. You could go and read Wadler&Blott's 1988 paper that formalised the typeclass system (and compared to ML and Miranda). You'll see exactly the same, and why Haskell is a huge improvement. > I'm going to open a new bug ticket soon. And that is not a request for information. Then you're going to be wasting a lot of people's time. Putting `1:2` at the GHCi prompt is a way to start learning, OK. You've spent 2~3 days at it. Most people get over it in an hour or so. I suggest you get on with some proper programming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 01:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 01:47:52 -0000 Subject: [GHC] #13972: GHC 8.2 error message around indexes for associated type instances is baffling In-Reply-To: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> References: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> Message-ID: <065.c6d1ed631f0e793ed6df1bfb1737bdb1@haskell.org> #13972: GHC 8.2 error message around indexes for associated type instances is baffling -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeFamilies, Resolution: | 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): Phab:D3820 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3820 Comment: I decided to go with approach (2) in Phab:D3820. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 03:33:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 03:33:09 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.a131655fa4580cc5126e0e9edeb23385@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): Replying to [comment:7 bgamari]: > * I can't reproduce the `conc038` failure I rebuilt GHC 8.2.1 today with ld override disabled, tested again and it's gone.\\ So I guess this is also caused by the linker problem. Without `--disable-ld-override`, I actually got the following error during the compiling phase: {{{ HC [stage 1] compiler/stage2/build/SysTools/Terminal.p_o HC [stage 1] iserv/stage2_p/build/GHCi/Utils.p_o HC [stage 1] libraries/time/dist-install/build/Data/Time/Format/Locale.o HC [stage 1] libraries/time/dist- install/build/Data/Time/LocalTime/Internal/TimeOfDay.o /usr/local/bin/ld.gold: fatal error: cannot mix -r with dynamic object /usr/lib/libthr.so collect2: error: ld returned 1 exit status `gcc5' failed in phase `Linker'. (Exit code: 1) gmake[1]: *** [iserv/ghc.mk:93: iserv/stage2_p/build/GHCi/Utils.p_o] Error 1 gmake[1]: *** Waiting for unfinished jobs.... gmake: *** [Makefile:127: all] Error 2 }}} Also, in rts/dist/build, `ffi.h` and `ffitarget.h` were reported missing during `make binary-dist`.\\ I'm not sure if these headers are needed, the ones in /usr/local/include (installed by libffi) are identical to what were packed in the official tarball.\\ (Did I miss some steps in the building process?) I've tried 3 different ways to bootstrap the build: * GHC 7.10.2 from ports * GHC 8.0.2 official binary distribution * GHC 8.2.1 itself It seemed that using 8.0.2 I could get the best test result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 11:51:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 11:51:14 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.31099ecf96a8ae2b1f4f89294e12baa9@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): Do you have a value for LIBRARY_PATH set? Could you run strace and attach the log? Or filemon. I'm after what ghci is loading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 12:05:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 12:05:08 -0000 Subject: [GHC] #14088: Allow users to omit`forall` Message-ID: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> #14088: Allow users to omit`forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Just an idea I wanted to get out there, I don't think it causes parsing ambiguity {{{#!hs -- id :: forall a. a -> a id :: a. a -> a -- everywhere :: (forall b. Term b => b -> b) -> (forall a. Term a => a -> a) everywhere :: (b. Term b => b -> b) -> (a. Term a => a -> a) }}} I think it looks beautiful but clearly more difficult to Google or grep for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 12:05:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 12:05:16 -0000 Subject: [GHC] #14088: Allow users to omit `forall` (was: Allow users to omit`forall`) In-Reply-To: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> References: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> Message-ID: <066.d804e4a94ee6ea8ebe10673bbcaaa128@haskell.org> #14088: Allow users to omit `forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 12:38:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 12:38:53 -0000 Subject: [GHC] #14088: Allow users to omit `forall` In-Reply-To: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> References: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> Message-ID: <066.a5863685d3de0a2a533fee83d11f5698@haskell.org> #14088: Allow users to omit `forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Hmm so {{{ f :: forall a b. a -> b -> a }}} becomes {{{ f :: a b. a -> b -> a }}} That initial `a b` looks like type application. {{{ g :: b.Foo -> Int }}} You probably meant {{{ g :: B.Foo -> Int }}} If you think `forall` is too verbose, you could use ∀ (?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 12:59:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 12:59:15 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.cab53d66063da54893abacd4471fb7cd@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Replying to [[span(style=color: #FF0000, AntC )]]:\\ I already know that. But your explanations, here and even above, lack precision and technicality. You should have said:\\ {{{ In Haskell, every expression must have a type, which is calculated prior to evaluating the expression by a process called "type inference". Graham Hutton, page 22, Chap 3, Types and classes. }}} I got the wrong word by writing evaluate instead of calculated. I do not speak the English language well. And sometimes I don't use the right words in my sentences.\\ But you also have to make an effort to understand.\\ Despite my lack of English language I make a lot of effort to read the best books about the Haskell language that are written in English. As you can see I also have other books about the Haskell language written by Hudak, Wadler, Bird.\\ I still get to understand what they are saying.\\ My sentences are sometimes poorly built and give the impression of dealing with a kid. But that is not true. I was already programming computers that you were not born yet.\\ Some of your writings have hurt me. * It is true I do not have the knowledge that you have of the Haskell language.\\ * I no longer have the age to write programs.\\ * Don't talk about my intellect. You don't know him.\\ * And you're the first one to tell me that I'm wasting your time.\\ One more thing:\\ I want this ticket closed by a member of the current Committee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 14:27:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 14:27:40 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.08d346308d3808e8fc816d8a819d427c@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The role of the Committee is to decide on [https://github.com/ghc- proposals/ghc-proposals proposals]. That's it. We have no special authority here on Trac. GHC is a community-based compiler, and this is a community forum for posting and debating deficiencies in GHC. Bugs generally are instances where GHC's observable behavior differs from either the Haskell Report or its own manual. (I say "generally", because the manual is sometimes not as well-specified as it could be and thus the discrepancy may be a matter of interpretation. The Report is much tighter.) If some behavior in GHC conforms to the Report/manual, then it is not a bug. If that behavior seems wrong in some way (even if it matches the Report/manual), you may want to consider writing a proposal to change it. So: for the behavior originally reported above, do you see a way in which GHC's behavior differs from what should be expected from the Report and/or manual? We (@hsyl20, @AntC, and myself, at least) do not see such a discrepancy. This is why the ticket was closed. However, if you could point out the discrepancy -- not appealing to "logic" or "intuition", but appealing to the text of the Report and/or manual -- then perhaps we are the ones mistaken. On the other hand, if there is no discrepancy, please close the ticket. PS: I always think it's best if we assume good intentions on everyone's behalf and avoid discussions of individuals' characteristics (intellect, age, etc.). I've had a good many times where I've felt someone was wasting my time only to find, at the end of a long conversation, I've learned something new and interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 15:47:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 15:47:34 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.25596def36f7f3a87c1ac7161b0f7fe7@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Reply to [[span(style=color: #FF0000, goldfire )]]:\\ Oh, I'm glad to read you, goldfire. OK. I understand. I have nothing in mind for the moment. I close this ticket.\\ One more thing: You're doing a good job, Ben and Ryan too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 15:50:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 15:50:57 -0000 Subject: [GHC] #14088: Allow users to omit `forall` In-Reply-To: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> References: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> Message-ID: <066.bfaa46337261858997815107d9f690e4@haskell.org> #14088: Allow users to omit `forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't support this idea. The issue is that in a type signature like `forall a b. a b`, there are two different varieties of type variables. There are type variable //binders// which appear between the `forall` and the dot (e.g., the `a` and `b` in `forall a b.`), and type variable //types//, which occur to right of the dot (e.g., the `a` and `b` in `. a b`). Syntactically, however, the difference between these two is not always so clear. This is where the `forall` keyword is extremely helpful to the reader. It gives a clear indication that what follows are type variable binders and not proper types. If we allow `forall` to be omitted, however, mentally parsing type signatures will become more of a chore. For instance, if you have this type signature: {{{#!hs f :: a b c d e f g h i j k l m n o p q r s t u v w x y z aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu vv ww xx yy zz. a b c d e f g h i j k l m n o p q r s t u v w x y z aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu vv ww xx yy zz }}} When I start reading the type of `f`, I have no idea if I'm looking at binders or types. I have to reserve extra lookahead to figure out what I'm looking at. With `forall`, this isn't an issue, because I can know instantly where the binders start. I'm not even sure what omitting `forall` even buys you. As AntC says, if you wish to write terser code, this is a perfectly cromulent thing to do: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE UnicodeSyntax #-} id :: ∀ a. a -> a id x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 16:17:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 16:17:09 -0000 Subject: [GHC] #14088: Allow users to omit `forall` In-Reply-To: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> References: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> Message-ID: <066.8eebf10f826a6b9c59437f58c278d34e@haskell.org> #14088: Allow users to omit `forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Iceland_jack): * status: new => closed * resolution: => wontfix Comment: Yeah I didn't think this would gain traction and I agree that it complicates parsing, but it was too cute not to get the idea out. Thanks for the feedback! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 16:21:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 16:21:19 -0000 Subject: [GHC] #14089: Segmentation fault/access violation using Yesod and Postgresql Message-ID: <048.46aff377a8018fc7c501ce75cd3dd62b@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql --------------------------------------+--------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: --------------------------------------+--------------------------------- When trying to build a Yesod site with Postgresql I got the following: I tried to use PostgreSQL and got the following: website-0.0.0: configure (lib) Configuring website-0.0.0... website-0.0.0: build (lib) Preprocessing library website-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package website-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- file" Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 16:21:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 16:21:44 -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.c1ecf182b1a907e4475e1c0b7314ceee@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | ---------------------------------+-------------------------------------- Description changed by Burtannia: Old description: > When trying to build a Yesod site with Postgresql I got the following: > > I tried to use PostgreSQL and got the following: > > website-0.0.0: configure (lib) > Configuring website-0.0.0... > website-0.0.0: build (lib) > Preprocessing library website-0.0.0... > [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- > work\dist\ca59d0ab\build\Settings.o ) > [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, > .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) > Segmentation fault/access violation in generated code > > -- While building package website-0.0.0 using: > C:\sr\setup-exe-cache\x86_64-windows\Cabal- > simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- > work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- > file" > Process exited with code: ExitFailure 1 New description: When trying to build a Yesod site with Postgresql I got the following: website-0.0.0: configure (lib) Configuring website-0.0.0... website-0.0.0: build (lib) Preprocessing library website-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package website-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- file" Process exited with code: ExitFailure 1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 16:22:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 16:22:06 -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.789447603f36ea46e70117bcddf539a6@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 Burtannia): * version: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 16:39:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 16:39:39 -0000 Subject: [GHC] #13737: Have typechecking produce HsType Typechecked instead of Type In-Reply-To: <047.10980034e11b4870fb14c5cc4724de83@haskell.org> References: <047.10980034e11b4870fb14c5cc4724de83@haskell.org> Message-ID: <062.1346ae0307cb29738ae416a7c88b7ef8@haskell.org> #13737: Have typechecking produce HsType Typechecked instead of Type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 17:12:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 17:12:17 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.4342d8bdca30dd7fe3a438d32cbff504@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): > It sounds like we will need separate bindists for OpenBSD 6.0 and 6.1. Arg. Thanks for the bindist! For the record, that seems to be the general rule for OpenBSD—their minor releases aren't necessarily compatible, as we learned on the stack side :-|. Let me quote https://github.com/commercialhaskell/stack/issues/416#issuecomment-282689118: > I've asked the OpenBSD mailing list whether static binaries compiled on an older release (X) are expected to run on a newer release (X+1, X+2) [0]. I've received the following - expected - answer from Sebastien Marie [1]: > >> The generic answer will be "no". >> >> The example is the switch from 5.4 to 5.5 release which included time_t change (32 to 64 bits) - see https://www.openbsd.org/faq/upgrade55.html#time_t >> >> But generally, an old binary (from release X) is able to run on a new kernel (from release X+1), but nothing more could be expected: old things are cleaned, so an old binary could be able to run or not (it just depends if relying on old API/ABI with kernel - syscalls, struct size...). > [0] http://marc.info/?l=openbsd-misc&m=148793092509010&w=2 > > [1] http://marc.info/?l=openbsd-misc&m=148793453010027&w=2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 19:38:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 19:38:07 -0000 Subject: [GHC] #13737: Have typechecking produce HsType Typechecked instead of Type In-Reply-To: <047.10980034e11b4870fb14c5cc4724de83@haskell.org> References: <047.10980034e11b4870fb14c5cc4724de83@haskell.org> Message-ID: <062.3905ea67a3b6a2ce7fce670655abcb53@haskell.org> #13737: Have typechecking produce HsType Typechecked instead of Type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Doing this would also benefit haddock as it currenly converts Type to HsType manually. This caused quite a few bugs in the past (the infamous "UnhelpfulSpan" error for example). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 20:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 20:01:20 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.ec27db7c9a3f9c1fb79c4b8d68e48f13@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | Phab:D3821 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: Phab:D3610 => Phab:D3610 Phab:D3821 Comment: Implemented {{{ -- | Adds a core plugin to the compilation pipeline. -- -- @addCorePlugin m@ has almost the same effect as passing @-fplugin=m@ to ghc -- in the command line. The major difference is that the plugin module @m@ -- must not belong to the current package. When TH executes, it is too late -- to tell the compiler that we needed to compile first a plugin module in the -- current package. addCorePlugin :: String -> Q () }}} See the phabricator diff for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 20:13:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 20:13:49 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.12420e2eb8073faac39cf6736f791fc6@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType 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): Has anyone checked whether 77bb09270c70455bbd547470c4e995707d19f37d had an impact here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 20:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 20:17:42 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions Message-ID: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- It seems that if the module is compiled with -O2 only the static pointers in the module export list survive the Simplifier. This is a regression. {{{ {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr staticHello :: StaticPtr String staticHello = static "hello" main = do keys <- staticPtrKeys if null keys then error "static ptrs are not being registered" else putStrLn "Everything is fine" }}} {{{ pepe:~/scratch$ stack --resolver ghc-8.2.1 script --optimize bug-spt.hs Using resolver: ghc-8.2.1 specified on command line bug-spt: static ptrs are not being registered CallStack (from HasCallStack): error, called at bug-spt.hs:11:10 in main:Main pepe:~/scratch$ stack --resolver ghc-8.0.2 script --optimize bug-spt.hs Using resolver: ghc-8.0.2 specified on command line Everything is fine }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 20:20:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 20:20:47 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.5e1dbbe5b741ff34caf46003daab4410@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mnislaih: Old description: > It seems that if the module is compiled with -O2 only the static pointers > in the module export list survive the Simplifier. This is a regression. > > {{{ > {-# LANGUAGE StaticPointers #-} > > import GHC.StaticPtr > > staticHello :: StaticPtr String > staticHello = static "hello" > > main = do > keys <- staticPtrKeys > if null keys > then error "static ptrs are not being registered" > else putStrLn "Everything is fine" > }}} > {{{ > pepe:~/scratch$ stack --resolver ghc-8.2.1 script --optimize bug-spt.hs > Using resolver: ghc-8.2.1 specified on command line > bug-spt: static ptrs are not being registered > CallStack (from HasCallStack): > error, called at bug-spt.hs:11:10 in main:Main > pepe:~/scratch$ stack --resolver ghc-8.0.2 script --optimize bug-spt.hs > Using resolver: ghc-8.0.2 specified on command line > Everything is fine > }}} New description: It seems that only the static pointers in the module export list survive the Simplifier. This is a regression which doesn't seem to affect ghci/runghc only compiled code. {{{ {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr staticHello :: StaticPtr String staticHello = static "hello" main = do keys <- staticPtrKeys if null keys then error "static ptrs are not being registered" else putStrLn "Everything is fine" }}} {{{ pepe:~/scratch$ stack --resolver ghc-8.2.1 script --optimize bug-spt.hs Using resolver: ghc-8.2.1 specified on command line bug-spt: static ptrs are not being registered CallStack (from HasCallStack): error, called at bug-spt.hs:11:10 in main:Main pepe:~/scratch$ stack --resolver ghc-8.0.2 script --optimize bug-spt.hs Using resolver: ghc-8.0.2 specified on command line Everything is fine }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 22:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 22:17:22 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.210392bbf8698d2c0a28c60ed7ec3525@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I've implemented a work-in-progress fix for GHC 8.2 [https://github.com/nh2/ghc/commit/d75bb46b6a16b4976a239442d90e5592ec439495 in this commit]. It's partly based on my older commit [https://github.com/nh2/ghc/commit/b23420378f68af9bddcced1cee08968779c505d0 b23420378f6]. It makes my example from the issue description work on the `-threaded` runtime on Linux (other platforms yet to be tested), but for unknown reason it doesn't fix it for the nonthreaded runtime. Maybe somehow in the nonthreaded runtime `timeout` doesn't actually throw the other thread the kill? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 22:24:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 22:24:05 -0000 Subject: [GHC] #14084: Strange behavior of GHC by writing the types in GHCi In-Reply-To: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> References: <044.6732ad61ac48b8f98ebf4af91d1429c9@haskell.org> Message-ID: <059.1f0befb494f4a0309969d1f96fcf5854@haskell.org> #14084: Strange behavior of GHC by writing the types in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 vanto]: > Some of your writings have hurt me. vanto, I apologise, I did not mean to hurt you. In both this ticket and #14076, you are saying something is wrong with Haskell/GHC. Several people patiently explained the behaviour is correct. They explained why it is correct. But you disagreed: "I'm going to open a new bug ticket soon ...". Please, before opening a ticket, think: maybe the behaviour is correct and there is something I don't understand. Then you can discuss that on another forum. People are very helpful on those forums: if they see some wrong GHC behaviour, they can help you open a bug ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 22:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 22:47:36 -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.6259b7b627b58ff08ffacb21942243b9@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 Phyx-): Hi, Do you have a way for me to reproduce this? What's this `website-0.0.0` ? Do you have a project I can use to trigger this? Just installing yesod doesn't seem to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 4 23:08:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Aug 2017 23:08:17 -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.9269283f8456f3513dee7af954fffb95@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 RyanGlScott): * status: new => infoneeded Old description: > When trying to build a Yesod site with Postgresql I got the following: > > website-0.0.0: configure (lib) > Configuring website-0.0.0... > website-0.0.0: build (lib) > Preprocessing library website-0.0.0... > [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- > work\dist\ca59d0ab\build\Settings.o ) > [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, > .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) > Segmentation fault/access violation in generated code > > -- While building package website-0.0.0 using: > C:\sr\setup-exe-cache\x86_64-windows\Cabal- > simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- > work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- > file" > Process exited with code: ExitFailure 1 New description: When trying to build a Yesod site with Postgresql I got the following: {{{ website-0.0.0: configure (lib) Configuring website-0.0.0... website-0.0.0: build (lib) Preprocessing library website-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack-work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package website-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8.0.2.exe --builddir=.stack- work\dist\ca59d0ab build lib:website --ghc-options " -ddump-hi -ddump-to- file" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 06:24:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 06:24:00 -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.2d07901dfb7baa02ac03557474bfb0ee@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 Burtannia): Replying to [comment:4 RyanGlScott]: Hi, the steps to reproduce are following the yesod quick start guide, I was using yesod-postgres at the time rather than yesod-sqlite: stack new project-name yesod-postgres && cd project-name stack build yesod-bin cabal-install --install-ghc stack build website-0.0.0 is because I named the project "website", if you called it potato then that package would be potato-0.0.0. ---- Running it now is giving me a different error: {{{ potato-0.0.0: build (lib + exe) Preprocessing library potato-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0 ab\build\Settings.o ) -- While building package potato-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8. 0.2.exe --builddir=.stack-work\dist\ca59d0ab build lib:potato exe:potato --ghc-o ptions " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure (-1073740940) }}} I then get a dialog box telling me ghc has stopped working. ---- If I use the yesod-sqlite template rather than yesod-postgres I get the same seg fault as before: {{{ emu-0.0.0: configure (lib + exe) Configuring emu-0.0.0... emu-0.0.0: build (lib + exe) Preprocessing library emu-0.0.0... [ 1 of 11] Compiling Settings ( src\Settings.hs, .stack- work\dist\ca59d0 ab\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, .stack- work\dist\ca59d0ab\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code -- While building package emu-0.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_1.24.2.0_ghc-8. 0.2.exe --builddir=.stack-work\dist\ca59d0ab build lib:emu exe:emu --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 16:12:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 16:12:45 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.ca8342266bc7568d9e8b42dfd1e247b3@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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: #13267 | Differential Rev(s): Phab:D3817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"a81b5b0067b6530f5883aeb0154a407a54d14c62/ghc" a81b5b00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a81b5b0067b6530f5883aeb0154a407a54d14c62" Remove the deprecated Typeable{1..7} type synonyms Summary: `Typeable{1..7}` (type synonyms for the poly-kinded `Typeable`) have been deprecated since GHC 7.8. They're now causing problems for users who try to still work with them in legacy code, since they can no longer be used in instances. To avoid this sort of confusion, let's just remove `Typeable{1..7}` altogether. Resolves #14047. Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14047 Differential Revision: https://phabricator.haskell.org/D3817 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 16:12:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 16:12:45 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.25e526e2ddbdabf606b285b128056de5@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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:D3819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"a267580e4ab37115dcc33f3b8a9af67b9364da12/ghc" a267580/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a267580e4ab37115dcc33f3b8a9af67b9364da12" Don't warn when empty casing on Type Summary: `Type` (a.k.a. `TYPE LiftedRep`) can be used at the type level thanks to `TypeInType`. However, expressions like ```lang=haskell f :: Type -> Int f x = case x of {} ``` were falsely claiming that the empty case on the value of type `Type` was non-exhaustive. The reason is a bit silly: `TYPE` is technically not an empty datatype in GHC's eyes, since it's a builtin, primitive type. To convince the pattern coverage checker otherwise, this adds a special case for `TYPE`. Test Plan: make test TEST=T14086 Reviewers: gkaracha, austin, bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #14086 Differential Revision: https://phabricator.haskell.org/D3819 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 16:14:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 16:14:11 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.63de55ec4329c1d75dbe09981c5e1d26@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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: #13267 | Differential Rev(s): Phab:D3817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: This is now "fixed", since `Typeable1` no longer exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 16:14:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 16:14:45 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.f4b5e3b785ba634283e235e8cf77a391@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | pmcheck/should_compile/T14086 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => pmcheck/should_compile/T14086 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 16:26:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 16:26:32 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.719554ca5c038a7ecebe4ebe8dd8fc4a@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): I just checked on HEAD, and the panic is not there anymore (with or without the fix to #14075). For the tip of the `8.2` branch, the panic is there with or without the fix to #14075. Interestingly, the panic when building `gi-gio` originally reported in #13803 is gone in HEAD if I include the fix to #14075 (otherwise it is still present). This is great! So I wonder if it is possible to backport to the `8.2` branch whatever fixed this in HEAD? Or alternatively, can you see any way of working around the panic reported above with `8.2`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 19:25:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 19:25:05 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.c49196f34e209368346d60fb550b22e5@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): For some reason, I'm unable to reproduce this on 64-bit Windows 10. I tried building `language-c-quote-0.11.7.1` with GHC 8.0.2, and `language-c-quote-0.12.1` with GHC 8.0.2 and 8.2.1, but neither of them segfaulted. Can you still trigger this segfault, awson? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 5 22:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Aug 2017 22:24:04 -0000 Subject: [GHC] #13823: Use NonEmpty lists in more places in the GHC API In-Reply-To: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> References: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> Message-ID: <065.ca1083b4c20909e7133a85a49f144a15@haskell.org> #13823: Use NonEmpty lists in more places in the GHC API -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8782 | Differential Rev(s): Phab:D3823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 00:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 00:45:48 -0000 Subject: [GHC] #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType Message-ID: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- We compile the following with -Wall {{{ {-# LANGUAGE PolyKinds #-} import Data.Bits import Data.Word data Hash128 a = Hash128 { hashWord128_0 :: !Word64, hashWord128_1 :: !Word64 } deriving (Show, Read, Eq) -- These instances copied from 'FixedPoint-simple': instance FiniteBits (Hash128 a) where finiteBitSize ~(Hash128 a b) = finiteBitSize a + finiteBitSize b instance Bits (Hash128 a) where popCount (Hash128 h l) = popCount h + popCount l bit i | i >= 64 = Hash128 (bit $ i - 64) 0 | otherwise = Hash128 0 (bit i) complement = pointwise complement (.&.) = pointwise2 (.&.) (.|.) = pointwise2 (.|.) xor = pointwise2 xor setBit (Hash128 h l) i | i >= 64 = Hash128 (setBit h (i - 64)) l | otherwise = Hash128 h (setBit l i) shiftL (Hash128 h l) i | i > finiteBitSize l = shiftL (Hash128 l 0) (i - finiteBitSize l) | otherwise = Hash128 ((h `shiftL` i) .|. (l `shiftR` (finiteBitSize l - i))) (l `shiftL` i) shiftR (Hash128 h l) i | i > finiteBitSize h = shiftR (Hash128 0 h) (i - finiteBitSize h) | otherwise = Hash128 (h `shiftR` i) ((l `shiftR` i) .|. h `shiftL` (finiteBitSize h - i)) isSigned _ = False testBit (Hash128 h l) i | i >= finiteBitSize l = testBit h (i - finiteBitSize l) | otherwise = testBit l i rotateL w i = shiftL w i .|. shiftR w (128 - i) rotateR w i = shiftR w i .|. shiftL w (128 - i) bitSize _ = 128 bitSizeMaybe _ = Just 128 pointwise op (Hash128 a b) = Hash128 (op a) (op b) pointwise2 op (Hash128 a b) (Hash128 c d) = Hash128 (op a c) (op b d) }}} get a warning like: {{{ Top-level binding with no type signature: pointwise2 :: forall k1 k2 k3 (a1 :: k2) (a2 :: k1) (a3 :: k3). (Word64 -> Word64 -> Word64) -> Hash128 a1 -> Hash128 a2 -> Hash128 a3 }}} but that's not a valid signature. Pasting it in causes GHC to suggest RankNTypes with an error, and then to suggest TypeInType, at which point it compiles. I want to just be able to paste in the signature from the warning. Related to #6065 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 00:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 00:46:29 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.06e634989925ae722e709dfbd415d65b@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): By the way, if the fix is really put off until 8.4.1, it means I'll have to skip a whole major version! This issue is a show stopper for my program, and I'd expect for any program that uses the GHC API for a REPL (maybe not that many, but still, it's a compelling GHC feature for me). It also makes interactive testing really slow, which for me makes it a show stopper for my style of development as well. If people like the "ghci allows but ignores -fhpc and -O" idea, I'd be happy to give the implementation a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 03:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 03:19:14 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c Message-ID: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: hs-boot. | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- duog's comment in https://phabricator.haskell.org/D3815#107812 pointed out an inconsistency between hs-boot handling in --make and -c that I have been dimly aware of for some time now. Here is how to trigger the situation: {{{ -- A.hs-boot module A where f :: Int -> Int -- B.hs module B where import {-# SOURCE #-} A -- A.hs module A where import B f :: Int -> Int f x = x + 1 -- C.hs module C where import {-# SOURCE #-} A g = f 2 }}} When we run `ghc-head C.hs --make -O -ddump-simpl -fforce-recomp`, we see that f has been successfully inlined: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} g :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] g = GHC.Types.I# 3# }}} However, if we then one-shot compile C.hs, as in `ghc-head -c C.hs -O -ddump-simpl -fforce-recomp`, the unfolding is not seen: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} C.g1 :: Int [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] C.g1 = GHC.Types.I# 2# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} g :: Int [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] g = f C.g1 }}} The crux of the matter is that `--make` and `-c` have different rules about when to make use of the unfolded definition. The `--make` rule is: compile the modules in some topological order. Any module that comes after `A.hs` sees the improved unfoldings. And as it turns out, the current topological order GHC picks is this: {{{ [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling C ( C.hs, C.o ) }}} The `-c` rule is more complicated. Every module records a list of transitive module dependencies, and whether or not a boot or non-boot was used. We load an hi-boot file if NONE of the modules we imported "saw" the full hi module, AND we only did direct SOURCE imports. If anyone has transitively imported A.hs, we load the hi file. In the example above, C.hs ONLY imports A.hs-boot, so hs-boot is obliged to load A.hi-boot, and thus it does not see the unfolding. The `-c` behavior is the correct behavior, because with the `--make` behavior it is easy to get into a situation where the build is dependent on the topological order chosen. Consider: * `A.hs-boot` * `B.hs-boot` * `A.hs` imports `A.hs-boot`, `B.hs-boot` * `B.hs` imports `A.hs-boot`, `B.hs-boot` (Ignore the fact that in GHC today you can't actually directly import your hs-boot file; you can fix this by importing dummy modules.) Now you can see that depending on the order you compile, e.g., A.hs-boot, B.hs-boot, A.hs, B.hs versus B.hs, A.hs, either A.hs or B.hs will be compiled with the unfoldings for its partner, but not vice versa. This doesn't sound good! Unfortunately, fixing things properly in `--make` mode is quite troublesome. To understand why, we have to first remind ourself about loop retypechecking in make mode. Remember that GHC knot-ties all of the typechecker data structures together (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot). This means that at the point we typecheck an hs-boot file, we are building an (immutable) graph on top of the impoverished, type signature only declarations from the hs-boot file. When we finish typechecking the loop closer, the only way to "update" all of the old references to the hs-boot file is to throw out the entire graph and rebuild it from scratch (the loop retypecheck!) So let's think about the A.hs-boot B.hs A.hs C.hs case. At the point we're typechecking A.hs, we throw out the graph referencing A.hs-boot and rebuild it referencing A.hs so that everything gets knot-tied to A.hs. But THEN, C.hs comes around, and it's like, "Oy, I don't want the A.hs version of the graph, I want the A.hs-boot version of the graph." In `-c` mode, this is not a problem, since we have to rebuild the graph from scratch anyway, but in `--make` this is a big deal, since we have to throw everything out and rebuild it AGAIN. One implementation strategy that doesn't involve mucking about with HPT retypechecking is to somehow make the typechecker aware of what unfoldings it should "see" and which it should not. The idea is that if it can ignore unfoldings that it doesn't have legitimate access to, that should be "just as good" as having typechecked against the hs-boot graph itself. But this sounds very tricky and difficult to get right... so here we are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 03:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 03:43:36 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.ebacfc0fd19fa28d86f5caa68d266a1c@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): The most relevant commit from me that might be how HEAD fixed it is 9e9fb57c37c62bb6c90f15b173c5d3632121c66a. If this commit isn't the needed one, more sleuthing will be needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 03:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 03:44:56 -0000 Subject: [GHC] #14093: GHC.Exe Panic (The 'Impossible' happened) Message-ID: <051.3d8c6321ecc767b0af6daa0323935679@haskell.org> #14093: GHC.Exe Panic (The 'Impossible' happened) -------------------------------------+------------------------------------- Reporter: ColonelTrick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Unfortunately, I am just learning Haskell, so I do not have the context to narrow this down to a narrow repro. Console Output: PS C:\Haskell> ghc -o creditCard .\CreditCards.hs [1 of 1] Compiling Main ( CreditCards.hs, Credit ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] n_a1PN :: t_a1PM[tau:1] (CHoleCan: n)} CreditCards.hs {{{#!hs -- Converts a number to digits toDigits :: Integer -> [Integer] toDigits n | n <= 0 = [] | otherwise = n `mod` 10 : toDigits (n `div` 10) -- Converts a number to digits and then reverses it toDigitsRev :: Integer -> [Integer] toDigitsRev n = reverse . toDigits n -- Doubles every other value doubleEveryOther :: [Integer] -> [Integer] doubleEveryOther[] = [] doubleEveryOther ([x:[]]) = [x] doubleEveryOther (x : y : zs) = x : 2 * y : doubleEveryOther zs -- Sums the digits of the credit card. sumDigits :: [Integer] -> [Integer] sumDigits [] = 0 sumDigits (x:xs) | x < 10 = x + sumDigits xs | otherwise = (x `mod` 10) + (x `div` 10) + sumDigits xs --- Inidicates whether the credit card is valid. validate :: [Integer] -> Bool validate x = (sumDigits (doubleEveryOther (toDigitsRev n)) `mod` 10) == 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 06:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 06:10:43 -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.c0ec60aa21513e6fbd172c83512e448f@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): Based on rwbarton's comment:1, it seems that GND should probably reject deriving ''any'' class whose last parameter is determined by a fundep. Is there something wrong with such a rule? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 06:30:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 06:30:40 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.e4239bea57f6c10005d5f817a929cf6b@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 awson): I can't. No segfault on 8.2.1 (and never was on 8.0.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 10:13:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 10:13:22 -0000 Subject: [GHC] #8033: add AVX register support to llvm calling convention In-Reply-To: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> References: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> Message-ID: <060.56594aa33dac69cf8e255ab99d3644d3@haskell.org> #8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by spacekitteh): it's been accepted. Bumping! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 12:32:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 12:32:10 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.d650ed9a7d0f36b64c71c2b1650c4fc7@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I like the "ghci allows but ignores -fhpc and -O" idea and I'd like to see this in 8.2.2. However see also https://ghc.haskell.org/trac/ghc/ticket/13002, not sure if "ghci allows but ignores -fhpc and -O" means that 13002 would not get resolved. As my original summary wrote this is a regression and I'd like to see it resolved sooner rather than later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 15:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 15:01:47 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.606ed5532650a39b70d4dde80a46cf3d@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): OK. The reason I ask is that another user recently reported experiencing a segfault on 64-bit Windows (#14089), and while I haven't tried reproducing the exact issue myself due to the sheer number of dependencies, the heavy use of Template Haskell in their project makes me wonder if this issue is the underlying culprit. Unfortunately, GHC 8.2.1 seems to have made it more difficult to trigger the particular case of `language-c-quote` giving a segfault. It seems doubtful that the issue just magically cured itself in the meantime, since the discussion above strongly suggests that we'll need to change the way GHC allocates memory on Windows to properly fix this. It would be nice if there were a minimal, dependency-less way of reproducing this so that we could continue investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 15:05:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 15:05:51 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.e5c41af926150e9683bead8beeefee06@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => duplicate * related: => #13106 Comment: Closing as a probably dupe of #13106. Please re-open if you experience the same issue on GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 15:07:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 15:07:08 -0000 Subject: [GHC] #14093: GHC.Exe Panic (The 'Impossible' happened) In-Reply-To: <051.3d8c6321ecc767b0af6daa0323935679@haskell.org> References: <051.3d8c6321ecc767b0af6daa0323935679@haskell.org> Message-ID: <066.706077c1bfdf0af6c6dc3f7013d27148@haskell.org> #14093: GHC.Exe Panic (The 'Impossible' happened) -------------------------------------+------------------------------------- Reporter: ColonelTrick | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * version: 8.2.1 => 8.0.2 * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. (On GHC 8.2.1, it would give a proper error that `n` is out of scope in the definition of `validate`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 15:17:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 15:17:28 -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.6a9bd43b8743770877363632a2134707@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): The problem isn't limited to just derived instances. If you try to write out the code that would be derived by hand: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} 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 }}} Then GHC will also "loop" (i.e., it will stack overflow on GHC 8.0.2 or later, and properly loop on GHC 8.0.1): {{{ • Reduction stack overflow; size = 201 When simplifying the following type: C a0 (Foo a) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: c a In an equation for ‘c’: c (Foo a) = c a In the instance declaration for ‘C b (Foo a)’ | 14 | c (Foo a) = c a | ^^^ }}} So if anything, we should be placing an extra check in the constraint solver, not just GND. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 16:10:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 16:10:33 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument In-Reply-To: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> References: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> Message-ID: <061.b1e0ef72694b3489a0bf24e7e3d098d1@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: ocheron Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: integer-gmp 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:D3826 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocheron): * owner: (none) => ocheron * failure: None/Unknown => Incorrect result at runtime * differential: => Phab:D3826 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 16:11:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 16:11:05 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument In-Reply-To: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> References: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> Message-ID: <061.de10cc1c7ff35d98cae10355c7154c0a@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: ocheron Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: integer-gmp 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:D3826 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocheron): Working on a patch I found another issue with `gcdExtInteger` when first argument is negative. Program: {{{#!haskell {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals f a b = let (# g, s #) = gcdExtInteger a b in (g, s) main = do print $ f 100000000000000000000000000000 7 print $ f (-100000000000000000000000000000) 7 }}} crashes with assertion when executed: {{{ $ ghc -V && ghc --make a The Glorious Glasgow Haskell Compilation System, version 8.2.1 [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... $ ./a (1,3) Assertion failed: (sn <= xn), function integer_gmp_gcdext, file libraries /integer-gmp/cbits/wrappers.c, line 315. Abort trap: 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 17:50:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 17:50:24 -0000 Subject: [GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families In-Reply-To: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> References: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> Message-ID: <065.7a6477aa5542a7b57775531d11f310f7@haskell.org> #13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 17:51:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 17:51:01 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings In-Reply-To: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> References: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> Message-ID: <061.0b70c8a6f004e8d7e163f488966b8d46@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ben, what's the status of the patch currently? Can you put it up on Phabricator and link here? Now that rules on datacons are banned, this should be safe to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 17:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 17:57:32 -0000 Subject: [GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families In-Reply-To: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> References: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> Message-ID: <065.7e2d7b3e84ac38338c18b92afd06fa4f@haskell.org> #13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Artyom.Kazak): > does it add a wrapper for instantiating What wrapper? (Just curious.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 18:28:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 18:28:08 -0000 Subject: [GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families Message-ID: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> #14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: deriving | 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: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} module Bug where class C a where type T a data D a m :: a instance C Int deriving instance C Bool }}} Neither `C` instance implements any of its type families or methods. However, the manual `C Int` instance and the derived `C Bool` instance give different warnings: {{{ GHCi, version 8.2.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:12:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘T’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:12:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘D’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:12:10: warning: [-Wmissing-methods] • No explicit implementation for ‘m’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^ Bug.hs:13:1: warning: [-Wmissing-methods] • No explicit implementation for ‘m’ • In the instance declaration for ‘C Bool’ | 13 | deriving instance C Bool | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notice that the `C Int` instance warns about the lack of an implementation for `T` and `D`, as expected. However, the derived `C Bool` instance does not. It only warns about `m`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 18:28:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 18:28:22 -0000 Subject: [GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families In-Reply-To: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> References: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> Message-ID: <065.fc6daf2cf9b60db85d47d3cbeca71255@haskell.org> #14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: deriving 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 RyanGlScott): * owner: (none) => RyanGlScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 19:49:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 19:49:16 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.b773ad3721d5ab0a8a37a6708b05c4ad@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 22:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 22:41:27 -0000 Subject: [GHC] #13299: Typecheck multiple modules at the same time In-Reply-To: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> References: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> Message-ID: <060.7a63333642410ec901b8f15d075f96d7@haskell.org> #13299: Typecheck multiple modules at the same time -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: 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 duog): * keywords: => hs-boot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 23:17:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 23:17:43 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.fb1e09ec7081cc1102d6f27ff5b0d3e9@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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 duog): * keywords: hs-boot. => hs-boot Comment: Thanks for this explanation ezyang, this is a very tricky area and I think I'm finally starting to understand what's going on. Note that your first example can be modified to exhibit another bug: to A.hs add {{{ h = f }}} to C.hs change to {{{ g = h 2 }}} This compiles in --make mode, even though C should not be able to see h! You say that -c behaviour is correct, and in the sense that it is predictable and deterministic, of course you are right. However, the current --make behaviour produces code that is at least as good(modulo the bug exhibited above), and in your first (A.hs-boot, B.hs, A.hs, C.hs) example, it is better! I wonder if it is possible to exploit laziness to always have unfoldings available even when importing an .hs-boot. trac:13299 seems relevant. I am currently working on an idea to split parsing, typechecking, simplifying, and codegen for the purpose of allowing more parallelism in --make mode. (I have a mostly-working patch, which I hope to have on phab this week, although it will be a little untidy). This might allow having unfoldings available from .hs-boot imports. Regarding "views" into the home package table, I think this may be a fruitful idea. It seems to me to offer nice solutions to this ticket, as well as trac:9370. :pieinthesky: I have thought of storing in interface files, instead of an unfolding, loosely a "map" of (way, OptimizationSettings)->unfolding. This would require the notion of views into the home package table. I think this would help address problems such as trac:10923. It would also allow eliminating the idea of "way" interfaces (.dyn_hi, .p_hi, etc), with all of that information in a single .hi file. I do admit that I'm not sure exactly what benefit removing way interfaces would provide, except that it does seem cleaner to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 23:22:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 23:22:30 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument In-Reply-To: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> References: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> Message-ID: <061.6ccf0845127bb780dcc8ac63aa232643@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: ocheron Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: integer-gmp 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:D3826 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Nice catch and thanks for working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 6 23:26:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Aug 2017 23:26:04 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.fffc18ca5fdf3487e61939bcc5e49034@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * component: GHCi => Compiler * milestone: 8.4.1 => 8.2.2 Comment: We can fix the checker for 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 00:14:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 00:14:09 -0000 Subject: [GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families In-Reply-To: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> References: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> Message-ID: <065.069a7157519e6515bf54382867a70d03@haskell.org> #14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: deriving 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:D3828 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 01:10:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 01:10:27 -0000 Subject: [GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families In-Reply-To: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> References: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> Message-ID: <065.b6f21936dcfc54738d12a015f75ea17e@haskell.org> #13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The reference to wrapper is more of an implementation detail. GHC uses a `HsWrapper` type to denote things that happen to expressions (instantiations, type abstractions, dictionary applications, etc.) that are invisible in user-written Haskell. That's all I was referring to there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 02:30:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 02:30:20 -0000 Subject: [GHC] #14082: -ddump-json does not escape quotes properly In-Reply-To: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> References: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> Message-ID: <065.0f8630de6348b8d30840ce494048478a@haskell.org> #14082: -ddump-json does not escape quotes properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * milestone: => 8.2.2 Comment: Fixed in e8fe12f83b17dc39d9272d44c4168946fa54e7a0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 02:53:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 02:53:21 -0000 Subject: [GHC] #14095: Improve parallelism in --make mode Message-ID: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> #14095: Improve parallelism in --make mode -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Currently, GhcMake.parUpsweep compiles modules in parallel, with each module waiting for all of it's dependencies to complete before proceeding. Parallelism is constrained by the -j flag, which limits the number of modules that may be compiled simultaneously. When multiple modules could be compiled next, ties are broken by a race to claim a semaphore. This ticket is about improving this parallelism, both by making it more finely-grained, and by more intelligently scheduling the next module to compile. This allows, for example, for code generation of modules compiled early to be delayed, so that other modules can be typechecked and simplified, unblocking their dependencies. I have a patch implementing the design described below, and I hope to have it on phab this week. It will be very much still a work in progress, however, some initial benchmarking suggests some quite good results, so I would very much appreciate feedback and help at this stage. The unit of operation of parUpsweep is a MakeTask, defined with some companion types as: {{{ data BuildModule = BuildModule ModuleName IsBoot data MakePipeline = MP_Parse | MP_Typecheck | MP_Simplify | MP_CodeGen data MakeTask = MakeTask BuildModule MakePipeline }}} As a module compiles, it starts parsing, then at the completion of hscParse', it moves to typechecking. Then, after desugaring it moves to simplifying, then after hscSimplify' moves to codegen. Note that a module can be parsed independently of it's dependencies. It can, in principle (I claim!), be typechecked once it's dependencies have been typechecked, and be simplified once it's dependencies have been simplified. It can be codegened independently of it's dependencies. In HscEnv, we store four IO actions in the following data type, {{{ data HscYield = HscYield { yieldParsedSource :: HscEnv -> ModSummary -> HsParsedModule -> IO () , yieldTypecheckedInterface :: HscEnv -> ModSummary -> ModIface -> Maybe ModDetails -> IO HomeModInfo , yieldSimplifiedInterface :: HscEnv -> ModSummary -> ModIface -> Maybe ModDetails -> IO HomeModInfo , awaitDependencyInterfaces :: HscEnv -> ModSummary -> IO () } }}} The first three members are called when a MakePipeline stage is complete. The fourth must be called to ensure all a module's dependent modules are present in the home package table. This is necessary at least during some codepaths in recompilation avoidance and safe haskell checking. All these IO actions will block, and return only once the next MakePipeline stage for that module has been scheduled to run. Calls to these functions are sprinkled through HscMain in strategic locations. We also change HscEnv.hsc_HPT to be an IORef HomePackageTable. I do expect this to be controversial, and even potentially unacceptable, and there are potentially alternate implementations on which I will not elaborate here. Note that responsibility for adding an interface to the home package table is on the implementer of yieldTypecheckedInterface and yieldSimplifiedInterface. In Ghc.parUpsweep we pre-compute a graph with nodes of MakeTasks and edges dependencies on other MakeTasks. We maintain a priority queue of MakeTasks whose dependencies are satisfied, where the priority is loosely an estimate of the work unblocked by completing that task. Whenever a MakeTask completes (and parUpsweep is notified via a call to a yield... function described above), the next MakeTask is dequeued from the priority queue and allowed to continue. There is some complication in the transition from typechecking to simplifying, and in ensuring the correct information is present in the home package table at the right time. Perhaps it is better to treat this as a single pipeline stage, and indeed, perhaps parsing as a separate pipeline stage does not pull its weight. I believe the split between simplify and codegen is where the majority of the benefit lies. Nevertheless, as is, it is working, so I must at least offer the full idea for consideration. I do understand that this will be difficult to understand or comment on without the code, and I'll endeavour to get it on phab as soon as I can, along with some benchmarks to motivate this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 02:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 02:54:16 -0000 Subject: [GHC] #14095: Improve parallelism in --make mode In-Reply-To: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> References: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> Message-ID: <058.0f8a88ccd527e317daaeab6c58540e85@haskell.org> #14095: Improve parallelism in --make mode -------------------------------------+------------------------------------- Reporter: duog | Owner: duog 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * owner: (none) => duog Comment: Claiming ownership, and noting that I've cc'd ezyang as a --make guru. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 03:27:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 03:27:51 -0000 Subject: [GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks In-Reply-To: <049.64e07177e9110058c04a019d46370d44@haskell.org> References: <049.64e07177e9110058c04a019d46370d44@haskell.org> Message-ID: <064.d4337c0e0d7bb1637781e4bc5994d593@haskell.org> #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): Is there a tutorial/readme on adding benchmarks to NoFib? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 03:42:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 03:42:48 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings In-Reply-To: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> References: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> Message-ID: <061.0a5f22372499d9994d9bcff0b4ea8f4f@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The patch is the `wip/simplifier-static` branch in my GitHub fork. I can't remember the precise status, but I do recall that the numbers weren't terribly promising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 05:47:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 05:47:22 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.422f9fd8cb257be86c988c30c7bec12e@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType 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 bgamari): I have not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 07:18:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 07:18:15 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks Message-ID: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The RTS panics when a program compiled with `-eventlog` is run with `+RTS -l -h`, {{{ trec-car-graph-expansion: internal error: getHeapProfBreakdown: unknown heap profiling mode Stack trace: 0x2122e2f set_initial_registers (rts/Libdw.c:288.0) 0x7f98bbdfb8b8 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.168.so) 0x7f98bbdfb347 (null) (/usr/lib/x86_64-linux- gnu/libdw-0.168.so) 0x7f98bbdfb673 dwfl_getthreads (/usr/lib/x86_64-linux- gnu/libdw-0.168.so) 0x7f98bbdfbc30 dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.168.so) 0x212342d libdwGetBacktrace (rts/Libdw.c:259.0) 0x2127aab rtsFatalInternalErrorFn (rts/RtsMessages.c:169.0) 0x2127c6d barf (rts/RtsMessages.c:47.0) 0x2136824 postHeapProfBegin (rts/eventlog/EventLog.c:1147.0) 0x21443bb initHeapProfiling.part.5 (rts/ProfHeap.c:464.0) 0x211cc16 hs_init_ghc (rts/RtsStartup.c:268.0) 0x2128bb3 hs_main (rts/RtsMain.c:63.0) 0x4cfc8d (null) (/home/ben/trec-car/mediawiki- annotate/dist-newstyle/build/x86_64-linux/ghc-8.2.1/trec-car-graph- expansion-0.1.0.0/c/trec-car-graph-expansion/bu ild/trec-car-graph-expansion/trec-car-graph-expansion) 0x7f98bba4a2b1 __libc_start_main (../csu/libc- start.c:325.0) 0x40ba1a _start (/home/ben/trec-car/mediawiki- annotate/dist-newstyle/build/x86_64-linux/ghc-8.2.1/trec-car-graph- expansion-0.1.0.0/c/trec-car-graph-expansion/bu ild/trec-car-graph-expansion/trec-car-graph-expansion) (GHC version 8.2.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 07:54:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 07:54:10 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.b4b903e2dd8837d3c53a3cd1f1d2e3a0@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): I have reset `PATH` to a standard value and `LIBRARY_PATH` is not set at all. Here's output of strace in cygwin: {{{ $ echo $LIBRARY_PATH $ export PATH="/bin/:/usr/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem" $ strace ./ghc/ghc-8.2.1-x32/bin/ghci -v3 WARNING: GHCi invoked via 'ghci.exe' in MinTTY consoles (e.g., Cygwin or MSYS) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 8.0.1 Using binary package database: C:\home\ghc\ghc-8.2.1-x32\lib\package.conf.d\package.cache package flags [] loading package database C:\home\ghc\ghc-8.2.1-x32\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.067 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.055 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 0.857 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.070 megabytes Access violation in generated code when reading 77b2ffff --- Process 2564 created --- Process 2564 loaded C:\Windows\SysWOW64\ntdll.dll at 77b20000 --- Process 2564 unloaded DLL at 77820000 --- Process 2564 unloaded DLL at 75b10000 --- Process 2564 unloaded DLL at 77820000 --- Process 2564 unloaded DLL at 77720000 --- Process 2564 loaded C:\Windows\SysWOW64\kernel32.dll at 75b10000 --- Process 2564 loaded C:\Windows\SysWOW64\KernelBase.dll at 77150000 --- Process 2564 loaded C:\Windows\SysWOW64\msvcrt.dll at 77590000 --- Process 2564 loaded C:\Windows\SysWOW64\user32.dll at 759d0000 --- Process 2564 loaded C:\Windows\SysWOW64\gdi32.dll at 774c0000 --- Process 2564 loaded C:\Windows\SysWOW64\lpk.dll at 77580000 --- Process 2564 loaded C:\Windows\SysWOW64\usp10.dll at 76000000 --- Process 2564 loaded C:\Windows\SysWOW64\advapi32.dll at 75e60000 --- Process 2564 loaded C:\Windows\SysWOW64\sechost.dll at 77130000 --- Process 2564 loaded C:\Windows\SysWOW64\rpcrt4.dll at 760a0000 --- Process 2564 loaded C:\Windows\SysWOW64\sspicli.dll at 75620000 --- Process 2564 loaded C:\Windows\SysWOW64\cryptbase.dll at 75610000 --- Process 2564 loaded C:\Windows\SysWOW64\imm32.dll at 757c0000 --- Process 2564 loaded C:\Windows\SysWOW64\msctf.dll at 75820000 --- Process 2564 loaded C:\Windows\SysWOW64\embdtrst.dll at 75130000 --- Process 2564 loaded C:\Windows\SysWOW64\apphelp.dll at 750e0000 --- Process 2972 created --- Process 2972 loaded C:\Windows\SysWOW64\ntdll.dll at 77b20000 --- Process 2972 unloaded DLL at 77820000 --- Process 2972 unloaded DLL at 75b10000 --- Process 2972 unloaded DLL at 77820000 --- Process 2972 unloaded DLL at 77720000 --- Process 2972 loaded C:\Windows\SysWOW64\kernel32.dll at 75b10000 --- Process 2972 loaded C:\Windows\SysWOW64\KernelBase.dll at 77150000 --- Process 2972 loaded C:\Windows\SysWOW64\gdi32.dll at 774c0000 --- Process 2972 loaded C:\Windows\SysWOW64\user32.dll at 759d0000 --- Process 2972 loaded C:\Windows\SysWOW64\advapi32.dll at 75e60000 --- Process 2972 loaded C:\Windows\SysWOW64\msvcrt.dll at 77590000 --- Process 2972 loaded C:\Windows\SysWOW64\sechost.dll at 77130000 --- Process 2972 loaded C:\Windows\SysWOW64\rpcrt4.dll at 760a0000 --- Process 2972 loaded C:\Windows\SysWOW64\sspicli.dll at 75620000 --- Process 2972 loaded C:\Windows\SysWOW64\cryptbase.dll at 75610000 --- Process 2972 loaded C:\Windows\SysWOW64\lpk.dll at 77580000 --- Process 2972 loaded C:\Windows\SysWOW64\usp10.dll at 76000000 --- Process 2972 loaded C:\Windows\SysWOW64\shell32.dll at 76380000 --- Process 2972 loaded C:\Windows\SysWOW64\shlwapi.dll at 75f10000 --- Process 2972 loaded C:\Windows\SysWOW64\wsock32.dll at 74fe0000 --- Process 2972 loaded C:\Windows\SysWOW64\ws2_32.dll at 75df0000 --- Process 2972 loaded C:\Windows\SysWOW64\nsi.dll at 75ad0000 --- Process 2972 loaded C:\Windows\SysWOW64\imm32.dll at 757c0000 --- Process 2972 loaded C:\Windows\SysWOW64\msctf.dll at 75820000 --- Process 2972 thread 2824 created --- Process 2972 thread 3052 created --- Process 2972 thread 3032 created --- Process 2972 thread 2436 created --- Process 2972 loaded C:\Windows\SysWOW64\ole32.dll at 76190000 --- Process 2972 loaded C:\Windows\SysWOW64\profapi.dll at 74ff0000 --- Process 2972 thread 1276 created --- Process 2972, exception c0000005 at 7717ece7 --- Process 2972 thread 2824 exited with status 0x1 --- Process 2972 thread 3032 exited with status 0x1 --- Process 2972 thread 1276 exited with status 0x1 --- Process 2972 thread 3052 exited with status 0x1 --- Process 2972 thread 2436 exited with status 0x1 --- Process 2972 exited with status 0x1 --- Process 2564 exited with status 0x1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 10:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 10:02:49 -0000 Subject: [GHC] #14095: Improve parallelism in --make mode In-Reply-To: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> References: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> Message-ID: <058.fad392a6fb261fe80a7746c5ddc600d9@haskell.org> #14095: Improve parallelism in --make mode -------------------------------------+------------------------------------- Reporter: duog | Owner: duog 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Great work, duog. I can't wait to see the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 10:39:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 10:39:14 -0000 Subject: [GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks In-Reply-To: <049.64e07177e9110058c04a019d46370d44@haskell.org> References: <049.64e07177e9110058c04a019d46370d44@haskell.org> Message-ID: <064.25710711d13013030f3dde222855bfd6@haskell.org> #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: 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): clinton, you can see an example here - https://phabricator.haskell.org/D3683. I still want to add more specific Eff benchmarks but they are a bit more difficult to add as you have to remove library dependencies by moving the relevant definitions into local files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 10:54:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 10:54:13 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.4f97a3e0ce54d4eea1cdb4376ac4bdbb@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): `-ddump-json` is a bit different to the other `-ddump` flags as the goal is to dump all the output (including the output of other -ddump flags) as machine readable JSON. The output of using `:set -ddump-json` looks more like I would have expected but I hadn't really considered the interaction with ghci. How do you think `-ddump-json` should work with the normal `ghc` executable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 11:22:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 11:22:57 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.83a4225c840b9c421cad65a1c493b624@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): This package has 123 modules which contain nothing else than a giant multi-kilobyte `String`. See https://hackage.haskell.org/package/skylighting-0.3.3.1/src/src/Skylighting/Syntax/Jsp.hs for example. With `-g` (DWARF) on `ghc-8.0.2` it appears to lead to ~40m compile times. I have a strong suspicion that we end up generating debugging information for each of these `(:)` cells, which is bound to be slow with 4 million of these total and the nesting levels of 10k. I may be wrong because #11095 was supposed to improve it and I'm running with https://git.haskell.org/ghc.git/commitdiff/29122312cc7b8f9890eb53f92d76ecdd8ded24ee already. I will try to confirm if the problem persists on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 11:45:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 11:45:40 -0000 Subject: [GHC] #14097: -ddump-json doesn't interact as expected with -ddump-to-file Message-ID: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> #14097: -ddump-json doesn't interact as expected with -ddump-to-file -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: JSON | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Usually with dump flags, if you set `ddump-to-file` then the dumped file will be outputted in the current directory if `-dumpdir` or `-ddump-file- prefix` is not set. This doesn't work with `-ddump-json`, if you do not specify `-ddump-file-prefix` then the output is always on stdout. Clearly stated, here are the two problems which I think have the same solution. 1. `-ddump-to-file -ddump-json` should output a file in the currect directory. 2. `-ddump-to-file -ddump-json` does not respect `-dumpdir` It seems that a stale set of DynFlags is used to direct the output of `-ddump-json`. The relevant function is `DynFlags.jsonLogFinaliser`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 11:49:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 11:49:31 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.a0a954278256b894308a105756baedba@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => JSON -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 11:50:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 11:50:47 -0000 Subject: [GHC] #14082: -ddump-json does not escape quotes properly In-Reply-To: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> References: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> Message-ID: <065.04b070448db185ef4da1b2423fde1e44@haskell.org> #14082: -ddump-json does not escape quotes properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => JSON -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 11:51:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 11:51:14 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.47e2923701c1adc70d28488bc700db5b@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => JSON -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 15:21:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 15:21:31 -0000 Subject: [GHC] #14097: -ddump-json doesn't interact as expected with -ddump-to-file In-Reply-To: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> References: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> Message-ID: <064.1a88f377f29bbb98b405ee076edc2ea1@haskell.org> #14097: -ddump-json doesn't interact as expected with -ddump-to-file -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The problem is that `dumpPrefix` is set in DriverPipeline but then this modified version of `DynFlags` is not propagated outwards and so it is not set at the time `jsonLogFinaliser` calls `dumpSDoc`. This means that `chooseDumpFile` fails as `dumpPrefix` is not set and the output is instead forwarded onto stdout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 15:32:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 15:32:44 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.0c9c1d7eb8045e4f441aad10ebb9cb97@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I got my libuv based tcp server running! It performs almost identical under my thinkpad w540, here's a quick benchmark numbers: {{{ ~/Code/stdio/bench/libuv(libuv*) » wrk -c1000 -d10s http://127.0.0.1:8888 winter at winter-thinkpad-w540 Running 10s test @ http://127.0.0.1:8888 2 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.58ms 4.35ms 233.38ms 99.16% Req/Sec 109.35k 16.85k 165.69k 65.66% 2158626 requests in 10.02s, 10.26GB read Requests/sec: 215444.90 Transfer/sec: 1.02GB }}} In contrast, here is the original I/O manager in base, aka mio: {{{ ~/Code/stdio/bench/libuv(libuv*) » wrk -c1000 -d10s http://127.0.0.1:8888 winter at winter-thinkpad-w540 Running 10s test @ http://127.0.0.1:8888 2 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 5.03ms 11.50ms 436.51ms 99.53% Req/Sec 106.39k 6.27k 124.92k 77.50% 2117274 requests in 10.07s, 10.07GB read Requests/sec: 210264.57 Transfer/sec: 1.00GB }}} The benchmark code is here: https://github.com/winterland1989/stdio/tree/libuv/bench/libuv What is interesting here is the `+RTS -s` figures, first is the mio one: {{{ 30,227,784,440 bytes allocated in the heap 4,608,251,832 bytes copied during GC 4,058,040 bytes maximum residency (1442 sample(s)) 4,537,568 bytes maximum slop 17 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 34042 colls, 34042 par 9.782s 2.468s 0.0001s 0.0074s Gen 1 1442 colls, 1441 par 4.523s 1.140s 0.0008s 0.0043s Parallel GC work balance: 75.40% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 24.940s ( 10.609s elapsed) GC time 14.305s ( 3.608s elapsed) EXIT time 0.002s ( 0.001s elapsed) Total time 39.248s ( 14.218s elapsed) Alloc rate 1,212,033,615 bytes per MUT second Productivity 63.5% of total user, 74.6% of total elapsed gc_alloc_block_sync: 357989 whitehole_spin: 1 gen[0].sync: 4817566 gen[1].sync: 326374 }}} Here's my libuv code's figure after `wrk` 's load: {{{ 6,666,812,808 bytes allocated in the heap 2,177,870,680 bytes copied during GC 3,574,680 bytes maximum residency (1370 sample(s)) 5,571,840 bytes maximum slop 16 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 6034 colls, 6034 par 4.802s 1.220s 0.0002s 0.0063s Gen 1 1370 colls, 1369 par 3.994s 1.010s 0.0007s 0.0025s Parallel GC work balance: 76.00% (serial 0%, perfect 100%) TASKS: 13 (1 bound, 12 peak workers (12 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 23.782s ( 13.182s elapsed) GC time 8.796s ( 2.230s elapsed) EXIT time 0.001s ( 0.001s elapsed) Total time 32.581s ( 15.413s elapsed) Alloc rate 280,326,860 bytes per MUT second Productivity 73.0% of total user, 85.5% of total elapsed gc_alloc_block_sync: 253553 whitehole_spin: 0 gen[0].sync: 3071193 gen[1].sync: 186169 }}} It seems that my new libuv based I/O manager reduce LOTS of allocations(maybe they're just moved to C side). Overall, i think my evaluation on libuv is successful, i'd like to discuss the possibilities to integrate it with base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 15:46:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 15:46:55 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.4a72a5f5b96060d7642b0471b500c33d@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Ignore what I said above, it's about a different version of skylighting which doesn't appear to have compile time issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 16:09:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 16:09:43 -0000 Subject: [GHC] #14097: -ddump-json doesn't interact as expected with -ddump-to-file In-Reply-To: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> References: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> Message-ID: <064.a3d2c0df92d8891fc59e37ac095607ca@haskell.org> #14097: -ddump-json doesn't interact as expected with -ddump-to-file -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: 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): There is quiet a fundamental problem that even if we propagate this information outwards, functions like `parUpsweep_one` operate in IO, on an exception this means that the updated dflags are not set and the output it still printed on stdout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 16:22:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 16:22:49 -0000 Subject: [GHC] #14097: -ddump-json doesn't interact as expected with -ddump-to-file In-Reply-To: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> References: <049.1e4f5406286eb0182a6f07fd0b23f79f@haskell.org> Message-ID: <064.6ef0e583dcf519f0c1e2fc689dc4ff0e@haskell.org> #14097: -ddump-json doesn't interact as expected with -ddump-to-file -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: 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): Well, the real problem here is that the way things are currently engineered, `-ddump-json` collects error messages for the entire compilation and then dumps them in one go. `dumpSDoc` is set up to dump things on a per-module basis, as such the log files are given the name of the current module they are dumping. Perhaps a better design for `-ddump- json` would be to output a JSON log on a module-by-module basis rather than collecting all the output. This would complicate the implementation a little as the messages would need to be sorted by module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 18:23:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 18:23:31 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.d9692a11759d4955b3cc223551596224@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Phab:D3831 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3831 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:48:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:48:05 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.aead1989564dd9a46769f748ac42c917@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------------------+------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | performance, Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Changes (by dfeuer): * Attachment "TH.2.hs" added. Updated TH -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:48:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:48:23 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.2d15b500eef2b775c0692baf0fc50eb2@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------------------+------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | performance, Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Changes (by dfeuer): * Attachment "Lib.2.hs" added. Updated Lib -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:48:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:48:41 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.9b0e3a17e7657a51f5fc424f6f0f0be8@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------------------+------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | performance, Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Changes (by dfeuer): * Attachment "Test.hs" added. Updated Test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:50:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:50:45 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.420b662811099b6f157eb503d53d9ec2@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: performance, 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): The original files no longer work with GHC 8.2.1 as a result of TH changes. I've uploaded new ones that do. Unfortunately, the bug is still with us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:57:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:57:37 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.77b6f6844a66ab7bfd898d5d399c3a36@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: performance, 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 "Test.hs" added. Updated Test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 19:57:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 19:57:37 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <046.74f1936d79aba164a77d583a6b851595@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: performance, 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 "Test.hs" removed. Updated Test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 20:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 20:05:35 -0000 Subject: [GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum In-Reply-To: <046.74f1936d79aba164a77d583a6b851595@haskell.org> References: <046.74f1936d79aba164a77d583a6b851595@haskell.org> Message-ID: <061.addc6fe9d2094d0975d6e61713f41c4f@haskell.org> #8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: performance, 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): Although there's still a bug, it has changed somewhat. We now get a context reduction stack overflow: {{{ Test.hs:43:8: error: • Reduction stack overflow; size = 201 When simplifying the following type: Functor (X201 :+: (X202 :+: (X203 :+: (X204 :+: (X205 ... Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: cata lift' In an equation for ‘lift’: lift = cata lift' | 43 | lift = cata lift' | ^^^^^^^^^^ }}} Removing the reduction depth limit brings my machine to its knees. I can compile the program with `n=120` and a reduction depth limit of 300. One other thing of note: removing the redundant `Functor` constraint on the `Lift f g` instance (which for some reason is not detected as redundant in 8.2.1, though it was in 8.0.2) improves matters considerably, but they're still pretty bad even in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 20:11:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 20:11:01 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.318e72e2a936084ac62d3b1bfd973cfb@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by sergv): * Attachment "ghci.tar.xz" added. Procmon traces of ghci process under cygwin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 21:51:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 21:51:24 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.13b58e69c260f3beb61c297bf99e0838@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): I really can't see anything see anything very suspicious in that log, only that it hasn't loaded any static archives I expected to see. I'll really need a dump or a linker log, but the latter requires a debug version of GHC. Question do all the machine it segfaults happen on are all equipped with Cygwin? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 22:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 22:30:45 -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.db9c1d32874c154b0e803d5cc3cf4fa1@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 Phyx-): Could you zip and attach the sample project. It's critical I can get a repro without stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 22:54:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 22:54:54 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs Message-ID: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language GADTs #-} data App f a where App :: f a -> App f (Maybe a) data Ty a where TBool :: Ty Bool TInt :: Ty Int data T f a where C :: T Ty (Maybe Bool) -- Warning f :: T f a -> App f a -> () f C (App TBool) = () -- No warning g :: T f a -> App f a -> () g C (App x) = case x of TBool -> () }}} When compiling, with `-Wincomplete-patterns`: {{{ Foo.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: C (App TInt) | 15 | f C (App TBool) = () | ^^^^^^^^^^^^^^^^^^^^ }}} I'm sorry for such a complicated example, but I wasn't able to reduce it any further than this. The gist of the problem is that this code gives a pattern matching non- exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to {{{#!hs data App f a where App :: f a -> App f a ... data T f a where C :: T Ty Bool }}} does not give a warning, even when `App` is modified further to force it to be a proper GADT. This might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug. Thanks to Iavor for helping me minimize the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 7 23:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Aug 2017 23:05:42 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.bff02a3829284c9518ae9f32ed6fe03c@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 jmgrosen): D'oh. Right after posting this, I found #11984, of which this looks like a duplicate, though this one is perhaps slightly simpler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 03:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 03:43:36 -0000 Subject: [GHC] #14099: Document fundeps Message-ID: <046.b800e01a492248ea0ae803c458700394@haskell.org> #14099: Document fundeps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: newcomers | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the documentation for functional dependencies in the GHC user's guide is quite poor. Fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 05:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 05:07:19 -0000 Subject: [GHC] #14099: Document fundeps In-Reply-To: <046.b800e01a492248ea0ae803c458700394@haskell.org> References: <046.b800e01a492248ea0ae803c458700394@haskell.org> Message-ID: <061.57b650d1666c40e8b10baa161fface16@haskell.org> #14099: Document fundeps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * related: => #13657 Comment: see also SPJ's comments on #13657 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 06:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 06:55:05 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.397ef1c55c87eca699d54649083d7e23@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): {{{ Question do all the machine it segfaults happen on are all equipped with Cygwin? }}} No, I opened this issue after trying on a virtual machine without Cygwin. I have removed Cygwin and tried again - crash is still there in msys 2.0. {{{ I'll really need a dump or a linker log, but the latter requires a debug version of GHC. }}} For some reason crash dumps are not collected, even though I followed the instructions you linked. I can try building a debug version of GHC and get it a go. Is this the right instructions to obtain debug ghc https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 07:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 07:56:20 -0000 Subject: [GHC] #14100: Nested NPlusKPatterns Message-ID: <043.ebbdad8e4d064c94fc61b26ef660bc7d@haskell.org> #14100: Nested NPlusKPatterns -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Nested patterns involving NPlusKPatterns cause a "parse error in pattern". Example appended below. > {-# LANGUAGE NPlusKPatterns #-} > {-# LANGUAGE ViewPatterns, PatternSynonyms #-} > infix 1 :^: > > data Bush elem = Nil | Bud elem | Bush elem :^: Bush elem > test ((n + 1) + 1) = n > pattern DivMod2 ∷ (Integral nat) ⇒ nat → nat → nat > pattern DivMod2 n k ← ((`divMod` 2) → (n, k)) where DivMod2 n k = 2 * n + k > braun ∷ Integer → Bush () > braun (0) = Nil > braun (1) = Bud () > braun (DivMod2 n k + 2) = braun (n + k + 1) :^: braun (n + 1) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 09:10:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 09:10:23 -0000 Subject: [GHC] #14100: Nested NPlusKPatterns In-Reply-To: <043.ebbdad8e4d064c94fc61b26ef660bc7d@haskell.org> References: <043.ebbdad8e4d064c94fc61b26ef660bc7d@haskell.org> Message-ID: <058.6eff80cdd7073964849f8bedd0164939@haskell.org> #14100: Nested NPlusKPatterns -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): You format Haskell code using {{{ {{{#!hs ... code }}} }}} ---- {{{#!hs {-# LANGUAGE NPlusKPatterns #-} {-# LANGUAGE ViewPatterns, PatternSynonyms #-} infix 1 :: data Bush elem = Nil | Bud elem | Bush elem :: Bush elem test ((n + 1) + 1) = n pattern DivMod2 ∷ (Integral nat) ⇒ nat → nat → nat pattern DivMod2 n k ← ((divMod 2) → (n, k)) where DivMod2 n k = 2 * n + k braun ∷ Integer → Bush () braun (0) = Nil braun (1) = Bud () braun (DivMod2 n k + 2) = braun (n + k + 1) :: braun (n + 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 09:48:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 09:48:24 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.db800bd5d4c42a34641c912b90d6d9ab@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Winter this is interesting. As you have setup the benchmark already. Could you provide a heap profile for ghc MIO? It would be interesting where the massive allocation come from. I think a simple +RTS -hT -RTS should suffice (no need to compile with -fprof, thanks Herbert for the tip). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 12:09:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 12:09:04 -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.56ca058e92d03b54956ce61bf304af0a@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 Burtannia): Replying to [comment:6 Phyx-]: > Could you zip and attach the sample project. It's critical I can get a repro without stack. I have zipped the postgres example and the sqlite example but they were too big to attach here. They are on dropbox at the following links: Postgres: https://www.dropbox.com/s/nbt8yxmkjmt1h0u/postgresExample.zip?dl=0 Sqlite: https://www.dropbox.com/s/mmjqxt49zw29mj3/sqliteExample.zip?dl=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 12:22:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 12:22:27 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.a5d138dba27511a89d08642bed88a319@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): > > For some reason crash dumps are not collected, even though I followed the instructions you linked. I can try building a debug version of GHC and give it a go. Is this the right instructions to obtain debug ghc https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler? If you can that would be really handy! as I can't see to reproduce it. https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows are the packages you'll need installed, then just copy `mk/build.mk.in` to `mk/build.mk` and uncomment the `devel2` line. Once building finishes, just do {{{ cd ghc make re2 GhcDebugged=YES }}} and it'll relink ghc using the debug runtime. you can then run ghci as {{{ inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS 2> linker.log }}} to dump a linker log. You can also try attaching it to gdb and see if it happened to have segfaulted in rts code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 15:04:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 15:04:49 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.9babcd36240f20696910c269a777d454@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: #11984 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #11984 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 15:05:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 15:05:34 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.d934b0e69c15e1ccb77da30441fdb83f@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #14098 Comment: See #14098 for a similar example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 19:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 19:58:56 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative Message-ID: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- {{{#!hs import GHC.Exts type Arr# = Array# data Foo a = Foo (Arr# a) type role Foo representational }}} produces {{{ error: • Role mismatch on variable a: Annotation says representational but role nominal is required • while checking a role annotation for ‘Foo’ }}} If the type synonym is instead defined {{{#!hs type Arr# a = Array# a }}} then it works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 20:04:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 20:04:25 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.68721773575a94d81a981fe3b5c49d04@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles 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): * keywords: => roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 20:13:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 20:13:01 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.010001881f49927b5eb1c597cccb4e69@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #8234 Comment: I'm guessing this may relate to the fix for #8234, but I couldn't really say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 20:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 20:18:17 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.cb2e9a6e7901c07c5e34b0724bedf8b2@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 20:36:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 20:36:46 -0000 Subject: [GHC] #13875: ApplicativeDo desugaring is lazier than standard desugaring In-Reply-To: <045.2eda858359df0999208d04da5f95a1da@haskell.org> References: <045.2eda858359df0999208d04da5f95a1da@haskell.org> Message-ID: <060.7403120422c98dd796b1ed53489a1ce4@haskell.org> #13875: ApplicativeDo desugaring is lazier than standard desugaring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ElvishJerricco): Replying to [comment:6 dfeuer]: > While I'm mentioning idle thoughts: monad comprehension syntax seems to handle the `pure`/`return`/`pure $`/whatever issue a lot more cleanly than anything `do`-like. Has anyone considered applicative comprehensions? This may no longer be the right place to answer this question, but I do think that using `in` would be better than special casing `return`, `pure`, and `$`. {{{ do a <- foo b <- bar in a + b }}} Seems more consistent with `let`-binding syntax. Though there is definitely some value in desugarring those functions since it means `ApplicativeDo` can be a drop-in optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 8 22:18:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Aug 2017 22:18:33 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.395f70a8d8bdedb166694bab33377d09@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My local fix for #12919 ''does'' fix this. But then a deeper bug lurks. The problem is that the `App` instance for `(:~>)` gets type-checked with a coercion in its patterns. Of course, the type-family matcher can't deal with a coercion pattern -- what would such a thing mean anyway? So it does something stupid. In this case, the stupid thing is that the match result contains an unbound variable, but it could conceivably do a different stupid thing tomorrow. The solution, of course, is to make sure that type patterns never contain coercions. I've been meaning to do this for a long time, regardless. (I don't think there's a ticket to track the idea, though.) I see two possible approaches: 1. Parameterize the code in TcHsType to know whether it's reading a pattern or a normal type, and don't make coercions in patterns. 2. Have TcHsType proceed normally, but rip the coercions out after-the- fact. What to do in the spots where the coercions used to be? Insert bare coercion variables, which can then be solved for. Some perhaps-outdated thoughts on this are [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Matchingaxioms here], but those notes were meant more for myself than anyone else. While we're thinking about this, another question I've pondered for a while: should type patterns be a separate datatype in GHC than `Type`? For example, a type pattern never has a type function nor a forall. It won't have meaningful `CastTy`s or `CoercionTy`s either. With this change, the pure unifier could perhaps be simplified. In any case, more thought is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 00:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 00:24:34 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.bef5f1ebcc9634672c1b0b323c271535@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't know what Jaffacake's opinion on this is but I'm not terribly keen on picking up a `libuv` dependency. We currently have very few native dependencies and I think that's a good thing; native dependencies are bound to either increase the complexity of the build system (if we statically link) or dramatically complicate distribution (if we dynamically link). If we could make the `libuv` backend optional and keep the existing codepath then maybe I can see us merge this, but otherwise it seems like we should simply try to optimize what we have rather than throw the whole thing away. I strongly suspect there is some very low-hanging fruit in mio. I'm willing to be convinced otherwise though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 00:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 00:59:43 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.8c6c247a2ec90c3e99111a6d980ea0b0@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * Attachment "libuv.hp" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 01:00:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 01:00:01 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.3edd0b1b4fc0790f71083a3638e82655@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * Attachment "mio.hp" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 01:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 01:20:06 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.8cf601f5e8b06f558c9cbf8f1f948b03@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I have attached the heap profile, the previous `+RTS -s` seems to be a mistake(I don't have a clue why it report such a big different), mio do allocate more memory, but that much. The benchmark parameters are: {{{wrk -c1000 -d10s http://127.0.0.1:8888}}} The request rate are {{{ libuv: Requests/sec: 264542.07 mio: Requests/sec: 236880.75 }}} > If we could make the libuv backend optional and keep the existing codepath then maybe I can see us merge this, but otherwise it seems like we should simply try to optimize what we have rather than throw the whole thing away. I personally feel no rush to change current base's I/O manager: it works well, and needed by GHCi. But since this ticket's purpose is to discuss the possibilities of integrate libuv, i would like to hear more. > native dependencies are bound to either increase the complexity of the build system (if we statically link) or dramatically complicate distribution (if we dynamically link). I'm interested in distribute my library with a statically linked libuv, is it possible with cabal? libuv is quite easy to build on unix, but i don't know the situation on windows, it seems require visual studio. > Further, it looks like libuv doesn't even support all of the platforms which GHC supports (OpenBSD, for instance). This is definitely not true, Node.js officially support OpenBSD so i don't see a reason why libuv not. I guess OpenBSD is just not on their CI. > I strongly suspect there is some very low-hanging fruit in mio. Can't say for libuv branch, but I think i got some other low-hanging fruit, e.g. i'm preparing the patch for `primitive` since you asked. It will include the `PrimArray a` and `class Arr (marr :: * -> * -> *) (arr :: * -> * ) a | arr -> marr, marr -> arr`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 01:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 01:26:55 -0000 Subject: [GHC] #14102: panic! (the 'impossible' happened) Message-ID: <047.2424c6620c704cc1994507a76d4a787b@haskell.org> #14102: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: pmckelvy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)} ******* code ******** import Data.Char import Data.List data InvoiceStruct = InvoiceStruct { total :: Int , shippedItemCount :: Int } deriving (Show) invoice :: InvoiceStruct -> String -> Int -> InvoiceStruct invoice i comp val = (action) i[total] val -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 02:48:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 02:48:33 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.f5973d11fa3b118c9514e20dd66a676f@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Here's my analysis on the allocate and performance difference: Mio's centre data structure is a fixed sized(32) stripped int-table(using grow only buckets), it maps fd to its callback function. The bucket usually is quite full since fd numbers follow the least unused rule. My libuv binding's centre data structure is variadic size(capatibily number) stripped int-table(also using grow only buckets), it map a range limited *slot* to a `MVar`. It actually works like a per capatibily stable pointer table: we keep a free list of slot waiting to be assigned, and during GC the int-table is evacuated. So mio have to allocate extra callback closure, even it's usually just a `putMVar`, but libuv doesn't: it simply use slots from eventloop to unblock those `MVar`s. Theoretically mio is more flexible since you can do pretty much anything inside callback, but in practise this's not a problem for libuv: after we unblock the blocking thread, it can do anything it want to, too. I plan to optimize the `MVar` table further using `primitive` 's `UnliftedArray` trick: it use `ArrayArray#` to directly save `MVar#` in packed memory. It will cut the GC time spending on the table(which is already very low) half. But i can't see how this optimization work out for mio. Another direction to go is to optimize our stable pointer's implementation and use the new `try_put_mvar` in 8.2. But I'm afraid it would not be as fast as my current version since current version is optimizied for libuv's call convention: provide buffers and handles, then wait for callbacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 03:19:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 03:19:02 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.aeef9053895bd9947d7548a5792fc364@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari, how hard do you think it would be to merge this to 8.0? 7.10? 7.8? Apparently there are still a few people using 7.6, but they should really give it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 05:42:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 05:42:00 -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.ad2d7c00ad978b82a73f22ad38ed3850@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: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): @RyanGlScott How did you trace usage of `bindLHsTyVarBndrs` to `rnValBindsLHS`? I was only able to trace it to `rnValBindsRHS` as @simonpj told: {{{ -- RnTypes.hs warnUnusedForAll ← bindLHsTyVarBndrs ← rnHsTyKi ← rnLHsType ← rnHsSigType ← -- RnBinds.hs renameSig ← rnValBindsRHS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 09:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 09:26:21 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.8d0542f126f723d6648c465eac49cabd@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merging likely wouldn't be terribly difficult. Building and releasing bindists, on the other hand, would require several days of effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 09:31:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 09:31:35 -0000 Subject: [GHC] #14102: panic! (the 'impossible' happened) In-Reply-To: <047.2424c6620c704cc1994507a76d4a787b@haskell.org> References: <047.2424c6620c704cc1994507a76d4a787b@haskell.org> Message-ID: <062.5bef5fd674f4769b7df803b7a52cd313@haskell.org> #14102: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: pmckelvy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Old description: > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)} > > ******* code ******** > import Data.Char > import Data.List > > data InvoiceStruct = InvoiceStruct > { total :: Int > , shippedItemCount :: Int > } deriving (Show) > > invoice :: InvoiceStruct -> String -> Int -> InvoiceStruct > invoice i comp val = (action) i[total] val New description: {{{ (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)} }}} Code: {{{#!hs import Data.Char import Data.List data InvoiceStruct = InvoiceStruct { total :: Int , shippedItemCount :: Int } deriving (Show) invoice :: InvoiceStruct -> String -> Int -> InvoiceStruct invoice i comp val = (action) i[total] val }}} -- Comment: Thanks for your report! This fails with the expected errors under 8.2.1, {{{ hi.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | import Data.Char | ^ hi.hs:10:23: error: Variable not in scope: action :: Main.InvoiceStruct -> [Main.InvoiceStruct -> Int] -> Int -> Main.InvoiceStruct | 10 | invoice i comp val = (action) i[total] val | ^^^^^^ }}} It's not entirely clear what fixed this but it's unlikely that we will release a 8.0.3 so I'm going to close this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 11:52:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 11:52:19 -0000 Subject: [GHC] #14102: panic! (the 'impossible' happened) In-Reply-To: <047.2424c6620c704cc1994507a76d4a787b@haskell.org> References: <047.2424c6620c704cc1994507a76d4a787b@haskell.org> Message-ID: <062.e587f56721abc6f5be78936f833dd92d@haskell.org> #14102: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: pmckelvy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13106 Comment: FWIW, this is a duplicate of #13106. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 12:11:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 12:11:35 -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.3b2bdc772afc64e044efab0d565b8de7@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, you're right, it is in fact `rnValBindsRHS` that handles the renaming of function type signatures, not `rnValBindsLHS`. My mistake. But my point about there being a chicken-and-egg problem is still relevant, I believe. Here is the [http://git.haskell.org/ghc.git/blob/14457cf6a50f708eecece8f286f08687791d51f7:/compiler/rename/RnBinds.hs#l287 current definition] of `rnValBindsRHS`: {{{#!hs rnValBindsRHS :: HsSigCtxt -> HsValBindsLR GhcRn GhcPs -> RnM (HsValBinds GhcRn, DefUses) rnValBindsRHS ctxt (ValBindsIn mbinds sigs) = do { (sigs', sig_fvs) <- renameSigs ctxt sigs ; binds_w_dus <- mapBagM (rnLBind (mkSigTvFn sigs')) mbinds ; let !(anal_binds, anal_dus) = depAnalBinds binds_w_dus ; let patsyn_fvs = foldr (unionNameSet . psb_fvs) emptyNameSet $ getPatSynBinds anal_binds valbind'_dus = anal_dus `plusDU` usesOnly sig_fvs `plusDU` usesOnly patsyn_fvs ; return (ValBindsOut anal_binds sigs', valbind'_dus) } rnValBindsRHS _ b = pprPanic "rnValBindsRHS" (ppr b) }}} Notice that the call to `renameSigs` (in which all `Unused quantified type variable` warnings are emitted) occurs before the call to `rnLBind` (which would handle, e.g., `SomeProxy (proxy @k @a)`). Moreover, this has to be the case, since the result of `renameSigs` is fed into `rnLBind`. This makes me believe that the `Unused quantified type variable` analysis needs to be moved out of `bindLHsTyVarBndrs` and somewhere that can take into account the results of `rnValBindsRHS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 13:27:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 13:27:23 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.c101221e21a0f04c118fa4de1c24255c@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire, RyanGlScott (added) Comment: At the very least, I know why that program is currently rejected. When role inference occurs, GHC uses the `tyConRolesX` function to look up the roles of a `TyCon`. The implementation of `tyConRolesX` is [http://git.haskell.org/ghc.git/blob/14457cf6a50f708eecece8f286f08687791d51f7:/compiler/typecheck/TcTyDecls.hs#l636 simply]: {{{#!hs lookupRolesX :: TyCon -> RoleM [Role] lookupRolesX tc = do { roles <- lookupRoles tc ; return $ roles ++ repeat Nominal } }}} In other words, if a `TyCon` is applied to more arguments than it was originally supplied in its definition, then the roles of these additional arguments will all be inferred as nominal. This is why the reported behavior only manifests when you define `Arr#` as `type Arr# = Array#`, and not `type Arr# a = Array# a`. Upon realizing this, my inclination to fix this bug is to simply expand all type synonyms during role inference. Indeed, if you apply this patch: {{{#!diff diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index 17da32f..512601f 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -2994,6 +2994,10 @@ checkValidRoles tc ex_roles = mkVarEnv (map (, Nominal) ex_tvs) role_env = univ_roles `plusVarEnv` ex_roles + check_ty_roles env role ty + | Just ty' <- coreView ty + = check_ty_roles env role ty' + check_ty_roles env role (TyVarTy tv) = case lookupVarEnv env tv of Just role' -> unless (role' `ltRole` role || role' == role) $ diff --git a/compiler/typecheck/TcTyDecls.hs b/compiler/typecheck/TcTyDecls.hs index 41482cc..6d70077 100644 --- a/compiler/typecheck/TcTyDecls.hs +++ b/compiler/typecheck/TcTyDecls.hs @@ -580,6 +580,8 @@ irDataCon datacon irType :: VarSet -> Type -> RoleM () irType = go where + go lcls ty | Just ty' <- coreView ty + = go lcls ty' go lcls (TyVarTy tv) = unless (tv `elemVarSet` lcls) $ updateRole Representational tv go lcls (AppTy t1 t2) = go lcls t1 >> markNominal lcls t2 diff --git a/compiler/types/Coercion.hs b/compiler/types/Coercion.hs index b0b13b8..214fe2d 100644 --- a/compiler/types/Coercion.hs +++ b/compiler/types/Coercion.hs @@ -1513,6 +1513,8 @@ ty_co_subst lc role ty = go role ty where go :: Role -> Type -> Coercion + go r ty | Just ty' <- coreView ty + = go r ty' go Phantom ty = lift_phantom ty go r (TyVarTy tv) = expectJust "ty_co_subst bad roles" $ liftCoSubstTyVar lc r tv }}} Then the program reported in this ticket compiles, and all tests pass. The more difficult question to answer, however, is if this is the correct way to go about things. At one point in time, it used to be possible to annotate type synonyms with role annotations, which would make the idea of eagerly expanding all type synonyms during role inference quite unsound. But post-#8234, role-annotating type synonyms isn't possible, so all (inferred) type synonym roles are as general as possible. This leads me to believe that expanding type synonyms eagerly would be sound. In any case, it'd be helpful to hear from Richard before we proceed further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 20:56:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 20:56:22 -0000 Subject: [GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules Message-ID: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: hs-boot | 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 time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7. In GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comments in Phab:3646. This isn't a big deal in practice, since .hs-boot modules are uncommon, but it does irk me, and it will be easy to fix. Fixing this would also be an opportunity to de-duplicate some logic in upsweep and parUpsweep. ccing niteria as he has worked with this code recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 9 21:10:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Aug 2017 21:10:26 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.11aec8ab61f87577953911f2607f555d@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Going from 8.0.2 to 8.2.1, things look very different right near the beginning, presumably as a result of the early inline patch. In 8.0.2, the first simplifier pass gives {{{ *** Simplifier [TextRegexTDFANewDFAEngine_FA]: Result size of Simplifier iteration=1 = {terms: 6,220, types: 14,606, coercions: 1,563} }}} whereas in 8.2.1 it gives {{{ *** Simplifier [TextRegexTDFANewDFAEngine_FA]: Result size of Simplifier iteration=1 = {terms: 17,641, types: 38,397, coercions: 10,258, joins: 30/233} }}} Things remain pretty bad until after float out, when they first get surprisingly good and then sort of oscillate. I'll take a look at the differences across the commits Ryan points out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 04:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 04:53:52 -0000 Subject: [GHC] #14095: Improve parallelism in --make mode In-Reply-To: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> References: <043.1ec42f2f435f9e5ba62298df17c56e70@haskell.org> Message-ID: <058.9eb2094d02b66b7d4cd24fab241005a9@haskell.org> #14095: Improve parallelism in --make mode -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: task | Status: patch 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: | Differential Rev(s): Phab:D3836 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => Phab:D3836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 08:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 08:58:38 -0000 Subject: [GHC] #14104: Pattern synonyms work where constructors fail Message-ID: <051.dea638219f6646bea3503cf941aa77ba@haskell.org> #14104: Pattern synonyms work where constructors fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This may be a bug. Taken from [https://www.reddit.com/r/haskell/comments/6so95h/why_do_pattern_synonyms_work_here_when/ reddit thread]: {{{#!hs {-# LANGUAGE DataKinds, FlexibleInstances, GADTs, MultiParamTypeClasses, PatternSynonyms, TupleSections, TypeFamilies, TypeFamilyDependencies, TypeOperators, ViewPatterns #-} -- ... type family Sum (ts :: [*]) = (t :: *) | t -> ts where Sum (t ': ts) = Either t (Sum ts) Sum '[] = Void pattern At :: (KnownNatural n, Index n ts) => SNatural n -> (ts !! n) -> Sum ts pattern At sn t <- (at -> Just (sn, t)) where At = toSum at :: (KnownNatural n, Index n ts) => Sum ts -> Maybe (SNatural n, ts !! n) at = fmap (sn,) . ofSum sn where sn = knownNatural class Index (n :: Natural) (ts :: [*]) where type (!!) ts n :: * toSum :: SNatural n -> (ts !! n) -> Sum ts ofSum :: SNatural n -> Sum ts -> Maybe (ts !! n) instance Index n ts => Index ('Succ n) (t ': ts) where type (!!) (t ': ts) ('Succ n) = ts !! n toSum (SSucc sn) = Right . toSum sn ofSum (SSucc sn) = either (const Nothing) (ofSum sn) instance Index 'Zero (t ': ts) where type (!!) (t ': ts) 'Zero = t toSum SZero = Left ofSum SZero = either Just (const Nothing) data Natural = Zero | Succ Natural data SNatural (n :: Natural) where SZero :: SNatural 'Zero SSucc :: SNatural n -> SNatural ('Succ n) class KnownNatural (n :: Natural) where knownNatural :: SNatural n instance KnownNatural 'Zero where knownNatural = SZero instance KnownNatural n => KnownNatural ('Succ n) where knownNatural = SSucc knownNatural }}} Using `SZero`, `SSucc SZero`, ... fails {{{#!hs type Trit = Sum '[(), (), ()] fromTrit :: Trit -> Int fromTrit (At SZero ()) = 0 fromTrit (At (SSucc SZero) ()) = 1 fromTrit (At (SSucc (SSucc SZero)) ()) = 2 }}} but making pattern synonyms succeeds {{{#!hs pattern S0 :: SNatural 'Zero pattern S0 = SZero pattern S1 :: SNatural ('Succ 'Zero) pattern S1 = SSucc S0 pattern S2 :: SNatural ('Succ ('Succ 'Zero)) pattern S2 = SSucc S1 type Trit = Sum '[(), (), ()] fromTrit :: Trit -> Int fromTrit (At S0 ()) = 0 fromTrit (At S1 ()) = 1 fromTrit (At S2 ()) = 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 08:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 08:59:51 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.65ca13e88460cd9fe5d3d755152cbdcd@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): That didn't work, unfortunately. If you have any other suggestion I would be glad to try, otherwise I will start bisecting... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 11:42:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 11:42:55 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries In-Reply-To: <046.811080f481e777da656f14add09b1cc8@haskell.org> References: <046.811080f481e777da656f14add09b1cc8@haskell.org> Message-ID: <061.fe3cdcda3e216c959a4c51973e747979@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 14:25:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 14:25:05 -0000 Subject: [GHC] #14104: Pattern synonyms work where constructors fail In-Reply-To: <051.dea638219f6646bea3503cf941aa77ba@haskell.org> References: <051.dea638219f6646bea3503cf941aa77ba@haskell.org> Message-ID: <066.6b89515443ef74d4c04bc524e89c04a1@haskell.org> #14104: Pattern synonyms work where constructors fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 behaving as expected. The types of the constructor `SZero` and the pattern synonym `S0` are almost the same, but not quite. You'll notice that if you leave off the type signature for `S0`, then `fromTrit` will fail to compile: {{{ Bug.hs:58:11: error: • Ambiguous type variable ‘n0’ arising from a pattern prevents the constraint ‘(KnownNatural n0)’ from being solved. Probable fix: use a type annotation to specify what ‘n0’ should be. These potential instances exist: instance KnownNatural n => KnownNatural ('Succ n) -- Defined at Bug.hs:42:10 instance KnownNatural 'Zero -- Defined at Bug.hs:40:10 • In the pattern: At S0 () In an equation for ‘fromTrit’: fromTrit (At S0 ()) = 0 | 58 | fromTrit (At S0 ()) = 0 | ^^^^^^^^ }}} Which is the same error you'd get if you tried using `SZero` in place of `S0` in the definition of `fromTrit`. The reason is that while the (written) type signature of `S0` is `SNatural 'Zero`, if you let GHC infer what it should be, then you'll get: {{{ λ> :i S0 pattern S0 :: () => n ~ 'Zero => SNatural n -- Defined at Bug.hs:47:1 }}} That is, `S0`'s inferred type is `SNatural n`, under the //given constraint// that `n` is equal to `Zero`. That is to say, in the context of a pattern match, we can only assume this equality //after// we've matched on it. This is why `fromTrit` is failing to typecheck with the constructor `SZero` (or `S0` with an inferred type), since we need evidence that `n ~ Zero` when matching on `At` (which comes before `SZero`/`S0`). To work around this issue, one can simply use the original pattern synonym type signatures, or one can try the workarounds that Syrak lists in this [https://www.reddit.com/r/haskell/comments/6so95h/why_do_pattern_synonyms_work_here_when/dlf50c9/ helpful comment]. Really, all of this is a symptom of the way typechecking GADT patterns works. Intuitively, one might expect that GHC gathers all of the given constraints in every pattern of a clause before typechecking each pattern, but that's not how it works. In practice, GHC typechecks patterns in a [https://ghc.haskell.org/trac/ghc/ticket/12018 left-to-right, inside-out fashion]. This is compositional and works predictably, but is has the downside that there some sequences of patterns that will only typecheck if ordered in a certain way (and alas, `At SZero` is not ordered the right way). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 14:54:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 14:54:21 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.d4f935cbb5b35476c3fc1589bdd80626@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In "Improve SetLevels for join points", everything is fine until liberate case. With the previous commit, this produces 34,318 terms, 54,571 types, 3,409 coercions, and 456/760 joins. With the SetLevels commit, this goes up to 57,468 terms, 83,821 types, 3,439 coercions, and 856/1,310 joins. It never makes up for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 16:48:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 16:48:30 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match Message-ID: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: ApplicativeDo | 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: -------------------------------------+------------------------------------- So this just happened: {{{#!hs {-# language ApplicativeDo #-} module Main where main :: IO () main = do [_] <- pure [] pure () }}} Compiling (under Stack) with `stack exec -- ghc --make src/Main.hs` yields {{{ [1 of 1] Compiling Main ( src/Main.hs, src/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): isStrictPattern Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This does not happen on GHC-8.0.2. It does not happen when `ApplicativeDo` is not activated. It also does not happen when the pattern match line is changed to {{{#!hs [] <- pure [] }}} For completeness, the compiler used by `stack` is that which comes with `nightly-2017-08-10`. I am on Linux x64 (Ubuntu). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 16:57:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 16:57:56 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.ef621383a5c12c468fff79469aeb844c@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo 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 alexbiehl): This is most likely due to a missing case for `ListPat` in `isStrictPattern`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 20:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 20:43:23 -0000 Subject: [GHC] #14106: Out of scope errors appear after type errors caused by them Message-ID: <048.46cf54e7237868a679805e12487d844f@haskell.org> #14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example: import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print .~ is out of scope, the error output: ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed. In larger examples, the out of scope error can be buried deep down. In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that. Out of scope errors should be put BEFORE any type errors that might be caused by them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 10 23:11:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Aug 2017 23:11:21 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.888ae5f90af15ef7e452a05f6e0b732e@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, it may be helpful to see what the additional bindings look like. This is when I would usually use my [[https://github.com/bgamari/ghc-dump|ghc- dump]] utility to dump a summary of the top-level bindings and their types. This should be easily diffable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 02:55:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 02:55:04 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.01ef34a20f3bf112346ea6842255cbd7@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Another thing to add is that, recently experiments showed that it's important to make a balance between unsafe nonblocking poll, e.g. `epoll_wait` with timeout zero and safe blocking poll, e.g. `epoll_wait` with timeout -1. Currently mio do two non-blocking poll, if still no events happend, mio sleep by doing a blocking poll. In stdio i use a idle counter, increased by one if last poll return no events. When the counter reach a limit(currently 50), stdio sleep by doing a blocking poll(using libuv's `UV_RUN_ONCE` mode). While this number doesn't affect normal load situation(since you never enter blocking poll in that case), it affect some light load situation, namely some benchmark code. The idle counter solution and 50 as a limit are borrowed from golang, which helped it win lots of benchmark i guess. In that case, mio just enter safe FFI too often. The mechanism is actually more complicated in stdio, since libuv never guarantee thread safety except a special `uv_async_t` handler(which behave like a control FD). We have to wake up the safe blocking call everytime we add new events. But this also give stdio a better ratio between unsafe and safe poll: everytime we wake from a blocking poll, we clean the idle counter so next 50 time poll will be unsafe one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 04:13:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 04:13:11 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.b08e848ef7140bdbaeb294c067c977b8@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 07:55:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 07:55:14 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.7e8d80cbc5dd955c9ff3f8d9426048d2@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by sergv): * Attachment "linker.log" added. Linker log produced by ghc commit 14457cf via "inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS 2> linker.log >&2" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 07:56:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 07:56:13 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.01fb8c5334a098d4746c822dbd0d490f@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): I have managed to reproduce the issue with ghc HEAD (+/- a few days) and attached linker log as requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 08:14:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 08:14:53 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.a4894b29057ffaa9eacea33ad9217c9f@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): Ah great, that's really useful, this seems to indicate the issue is in `initLinker_PEi386` during `addDLLHandle`. I just need one final piece which is where, since the segfault is in the rts and in C code this should be fairly easy. Could you run {{{ gdb --ex run --args inplace/bin/ghc-stage2.exe --interactive }}} with the debud build of ghc. once it crashes copy that trace and put that here, along with the output of running the `bt`, `info locals` and `info args` command. Finally run `gcore` to create a gdb core dump file and attach that. Should be able to figure what's wrong with those pieces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 10:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 10:46:15 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad Message-ID: <044.6302be4678eb9c4717101ae155816826@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.2.1 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: -------------------------------------+------------------------------------- Since IO implements `Semigroup` and `Monoid`, is there a good reason for `ST` not to implement those, too? I discovered the lack of those instances while using `foldMap` for code that used to use `IO` as the underlying monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 11:10:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 11:10:49 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.ff47c6b1799362cb0b96b10e92322388@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: Replying to [ticket:14107 plato]: > Since IO implements `Semigroup` and `Monoid`, is there a good reason for `ST` not to implement those, too? The reason is because no one has asked for them yet :) I'd have no issues with a patch that implemented this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 12:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 12:10:09 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.1e086c7eebb9f362b1a7ebd547afa48b@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Not only string literals could benefit from ByteArray# literals: Integer/BigNats could too! Currently big integer literals are desugared into a list of `Int` chunks. With ByteArray# literals we could represent them directly as a constant! Whats the status on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 12:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 12:57:32 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.b1458e5aec5fd19b1f63b5e68a5e3754@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): This bisects to a6e13d502ef46de854ec1babcd764ccce68c95e3, meaning that commit fixes the underlying problem. I cherry-picked it onto our `ghc-8.0.2-facebook` branch and the compile times are reasonable (~2min as opposed to >30m). I minified the original code to Skylighting.Syntax.Php.hs file that I'm attaching. It's boils down to a large `[Text]` list. With a commit before the fix there's a big blow up in the term size after one of the simplifier passes. After the fix the term sizes look reasonable. Relevant part of `-ddump-show-phases` (this is the released GHC 8.0.2, but the numbers are the the same before the fix): {{{ !!! Parser [Skylighting.Syntax.Php]: finished in 4556.00 milliseconds, allocated 87.667 megabytes [99/1907] *** Renamer/typechecker [Skylighting.Syntax.Php]: !!! Renamer/typechecker [Skylighting.Syntax.Php]: finished in 27009.00 milliseconds, allocated 241.752 megabytes *** Desugar [Skylighting.Syntax.Php]: Result size of Desugar (after optimization) = {terms: 16,197, types: 6,490, coercions: 0} !!! Desugar [Skylighting.Syntax.Php]: finished in 2024.00 milliseconds, allocated 22.967 megabytes *** Simplifier [Skylighting.Syntax.Php]: Result size of Simplifier iteration=1 = {terms: 22,671, types: 19,426, coercions: 0} Result size of Simplifier = {terms: 22,671, types: 19,426, coercions: 0} !!! Simplifier [Skylighting.Syntax.Php]: finished in 14080.00 milliseconds, allocated 150.808 megabytes *** Specialise [Skylighting.Syntax.Php]: Result size of Specialise = {terms: 22,678, types: 19,437, coercions: 2} !!! Specialise [Skylighting.Syntax.Php]: finished in 5593.00 milliseconds, allocated 32.625 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Skylighting.Syntax.Php]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 48,542, types: 58,233, coercions: 2} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Skylighting.Syntax.Php]: finished in 8951.00 milliseconds, allocated 126.301 megabytes *** Simplifier [Skylighting.Syntax.Php]: Result size of Simplifier iteration=1 = {terms: 45,307, types: 55,000, coercions: 0} Result size of Simplifier = {terms: 45,307, types: 55,000, coercions: 0} !!! Simplifier [Skylighting.Syntax.Php]: finished in 36008.00 milliseconds, allocated 394.685 megabytes *** Simplifier [Skylighting.Syntax.Php]: Result size of Simplifier iteration=1 = {terms: 55,006, types: 55,000, coercions: 0} Result size of Simplifier = {terms: 42,074, types: 22,670, coercions: 0} !!! Simplifier [Skylighting.Syntax.Php]: finished in 44152.00 milliseconds, allocated 564.940 megabytes *** Simplifier [Skylighting.Syntax.Php]: Result size of Simplifier iteration=1 = {terms: 1,060,469, types: 775,959, coercions: 193,980} Result size of Simplifier iteration=2 = {terms: 944,081, types: 824,454, coercions: 171,349} Result size of Simplifier iteration=3 = {terms: 827,693, types: 624,008, coercions: 38,796} Result size of Simplifier iteration=4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 12:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 12:58:01 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.a65b6b2ff5f8ceb17546310ffc231b5c@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "Skylighting.Syntax.Php.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 14:15:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 14:15:37 -0000 Subject: [GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules In-Reply-To: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> References: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> Message-ID: <058.c3591cb4ddc486c237e12b6a6f662b54@haskell.org> #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by niteria): If there's a cleaner way to do it, I'm all for it. I was conservative with my fix, because there was some code I didn't understand and I didn't want to change the behavior. For example: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/GhcMake.hs;14457cf6a50f708eecece8f286f08687791d51f7$895-905 If there are loops with multiple (say A.hs-boot, B.hs-boot, C.hs-boot) hs- boot modules, it would extract a cycle with A.hs-boot, B.hs-boot, C.hs- boot, a cycle with B.hs-boot, C.hs-boot, and a cycle with C.hs-boot. Why? I don't know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 14:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 14:16:23 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.cea2155a34b3844b29a3a05effe52e77@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.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 plato): Okay, I'll try to create one! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 14:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 14:41:31 -0000 Subject: [GHC] #14108: GHCi doesn't remember let-less function declarations with -fobject-code Message-ID: <050.c25f430b23baa32d72b0e3ee9006d0fb@haskell.org> #14108: GHCi doesn't remember let-less function declarations with -fobject-code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- GHCi supports two styles of function declaration: those using an explicit `let` keyword, and those without. This GHCi session demonstrates both: {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/Documents/Hacking/Haskell/trifecta/.ghci Loaded GHCi configuration from /home/rgscott/.ghci λ> let foo1 :: Int; foo1 = 42 λ> foo1 42 λ> foo2 :: Int; foo2 = 42 λ> foo2 42 }}} But if using GHCi with the `-fobject-code` enabled, then the `let`-less style of declaration no longer works: {{{ $ /opt/ghc/8.2.1/bin/ghci -fobject-code GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/Documents/Hacking/Haskell/trifecta/.ghci Loaded GHCi configuration from /home/rgscott/.ghci λ> let foo1 :: Int; foo1 = 42 λ> foo1 42 λ> foo2 :: Int; foo2 = 42 λ> foo2 :4:1: error: • Variable not in scope: foo2 • Perhaps you meant ‘foo1’ (line 1) }}} Originally noticed [https://github.com/ekmett/trifecta/pull/73#issuecomment-321829537 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 14:50:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 14:50:42 -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.b90c55c1dc50dd42d87121e911f9b8d1@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 RyanGlScott): Thanks Burtannia. I tried building each of these examples with both GHC 8.0.2 and 8.2.1. Neither example segfaulted on GHC 8.2.1. On GHC 8.0.2, the `postgres` example didn't segfault, but the `sqlite` example did: {{{ $ cabal build Preprocessing library for sqliteExample-0.0.0.. Building library for sqliteExample-0.0.0.. [ 1 of 11] Compiling Settings ( src\Settings.hs, dist\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, dist\build\Settings\StaticFiles.o ) [ 3 of 11] Compiling Model ( src\Model.hs, dist\build\Model.o ) [ 4 of 11] Compiling Import.NoFoundation ( src\Import\NoFoundation.hs, dist\build\Import\NoFoundation.o ) [ 5 of 11] Compiling Foundation ( src\Foundation.hs, dist\build\Foundation.o ) Segmentation fault/access violation in generated code }}} Running `cabal build` after this causes the build to succeed. However, `cabal clean`-ing and re-running `cabal build` causes the segfault to resurface: {{{ $ cabal build Preprocessing library for sqliteExample-0.0.0.. Building library for sqliteExample-0.0.0.. [ 1 of 11] Compiling Settings ( src\Settings.hs, dist\build\Settings.o ) [ 2 of 11] Compiling Settings.StaticFiles ( src\Settings\StaticFiles.hs, dist\build\Settings\StaticFiles.o ) Segmentation fault/access violation in generated code }}} Notice that it appeared to segfault in a different location that time! Moreover, you appear to need to build these modules in parallel (`cabal build`'s default behavior) to trigger the segfault (at least, on my 64-bit Windows 10 machine), since I can't get it to segfault with `cabal build -j1`. My initial hunch is that this is an occurrence of #13112, since both `Foundation` and `Settings.StaticFiles` use quite a bit of Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 11 16:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Aug 2017 16:35:51 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.3444fe3371d05c36db18840a5c923966@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Sorry -- I wrote a post here but somehow it got lost. (I'm sure this is my fault.) This is by design. Any non-nominal role on a type parameter must be assigned to a proper type parameter to that type. When you eta-reduce, there's no place to put the non-nominal role. Happily, Ryan's patch solves the problem and looks utterly correct to me. So, while the synonym's argument's role is still nominal, that fact becomes irrelevant during role inference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 02:16:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 02:16:09 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.ce9aafb25bcb8472a585bf5b5ba4fb9c@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3838 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 02:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 02:37:05 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.fc1e8f83562e2bb2bbec37d41d4c9826@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | 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): D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * status: new => patch * differential: => D3839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 02:37:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 02:37:23 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.a4d23bec4f84f86956c58a4f42ba6b70@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): My concern is that this might not always do the best job with closed type families. In particular, we can produce a bound on the role of an application of a closed type family even if we can't reduce it. {{{#!hs type family Foo a where Foo 'True = Maybe Foo 'False = Either Int newtype Bar a b = Bar (Foo a b) }}} We know that `Foo a` must be `Maybe`, `Either Int`, or stuck. I believe it should therefore be safe to give `b` a representational role. My guess is that the right thing is to give type signatures and closed type families role annotations with the number of components determined by the number of arrows in their kinds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 02:46:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 02:46:30 -0000 Subject: [GHC] #12155: Description of flags cut off In-Reply-To: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> References: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> Message-ID: <060.b96a40604632c783b762eff939229d81@haskell.org> #12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: (none) Type: task | Status: patch Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: flags Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #11654 | Differential Rev(s): D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * status: new => patch * differential: => D3839 * related: => #11654 Comment: This was wrapped into the change from `mkUserGuidePart` to Sphinx based generation. Tables are manually sized in `flags.rst`, but even still it's not perfect. LaTeX can't break flags like `-XGeneralizedNewtypeDeriving`, which means that the sum of the minimum column widths is larger than the width of the line. I believe there aren't any egregious overlaps remaining, but some flags do spill out of their cells. Column widths are set in a percentage format that looks like `|\Y{20}|\Y{40}|\Y{10}|\Y{30}|`, which is reasonably amenable to change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 06:52:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 06:52:02 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.8378435a360f716098e9507f0cb27db1@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): This is a serious regression, breaking most applications that use `-XStaticPointers`. Facundo, could you have a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 08:23:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 08:23:15 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.45047c392ef78811cc156f785031a884@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ethercrow): I'm not sure if it belongs to this ticket. I'm trying to make a specialization for leaves in a hashmap when key type is something small, e.g. Int: {{{ data LeafInt v = LI !Int v data LeafPoly k v = LP !k v type family Leaf a where Leaf Int = LeafInt Leaf k = LeafPoly k }}} The hashmap {{{ data HashMap k v = Leaf !Hash !(Leaf k v) ... }}} itself has a type role annotation: {{{ type role HashMap nominal representational }}} I get the error {{{ • Role mismatch on variable v: Annotation says representational but role nominal is required • while checking a role annotation for ‘HashMap’ }}} I tried to express the same using data family and a class with associated type, the result is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 08:41:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 08:41:59 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.1bdbd465093085f3213bcdace434bd65@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * cc: ethercrow (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 08:42:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 08:42:27 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.9beaea96d3bb49207ea6f3f9fbc6b6d9@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * cc: ethercrow (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 10:54:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 10:54:41 -0000 Subject: [GHC] #13203: Implement Bits Natural clearBit In-Reply-To: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> References: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> Message-ID: <059.98fc257115022a388c6fe34f46853b51@haskell.org> #13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: supersven Type: bug | Status: new Priority: lowest | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 11:51:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 11:51:50 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.ecf1049d47e9d5253b0b80f47c9340a5@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): For some reason `gdb` does not produce a stacktrace and cannot find any symbols. Can you please check if I'm doing anything obviously wrong in the attached gdb log? I also took a look at the list of dlls loaded by the `ghc-stage2.exe` process in the process explorer and noticed that it loads two copies of `ntdll.dll`. One is loaded from `C:\Windows\System32\` and another is loaded from `C:\Windows\SysWOW64\`. Can this cause any problems? I'm attaching list of dlls as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 11:53:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 11:53:09 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.f2a08d08dbada6d815b25766df38d1a0@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by sergv): * Attachment "gdb.log" added. Log produced by 'gdb -ex run --args ./inplace/bin/ghc-stage2.exe --interactive +RTS -Dl' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 11:53:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 11:53:31 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.d619c4884d61c7cd936f666d94aa574a@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by sergv): * Attachment "process-explorer.txt" added. List of dll at the time ghc-stage2.exe crashed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 12:13:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 12:13:15 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.20b3cb73bef4f09455f1628df7c9b6cf@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): The list of dlls is fine, it's just the system redirecting the load. Had it somehow been able to load the 64bit one then we would have gotten an image load error. GDB not showing a trace is unfortunately quite common during the RTS's startup code. something screws up the stack frame during init. use `break addDLLHandle if ((int)strcmp(dll_name, "ntdll.dll")) == 0` and then step through the source with `next`. My guess is you'll segfault after a few steps. If you do make a note of which statement it was. restart and step to just before the segfault and run `gcore` for a dump. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 12:45:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 12:45:47 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.be5c2c2e5eb29ab85ca93df5b63d5507@haskell.org> #14057: Upstream Alpine Linux distribution patches ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by tuncer): * os: Unknown/Multiple => Linux * milestone: 8.4.1 => 8.2.2 Comment: Changed Milestone to 8.2.2 as per discussion with Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 13:40:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 13:40:23 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.b9cf4491bb7c9072f4f2b3a1d507db77@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): The {{{staticHello}}} binding is dropped during desugaring. More specifically, during a call to {{{ simpleOptPgm :: DynFlags -> Module -> CoreProgram -> [CoreRule] -> [CoreVect] -> IO (CoreProgram, [CoreRule], [CoreVect]) }}} I'm new to this code, so any insights are welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 14:20:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 14:20:32 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.d5a60ed4ab85b842ac87304a8b3ebcd6@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.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 plato): I dug into the source code and have two questions: 1. Adding the `Monoid` and `Semigroup` instances was simple enough, but I noticed some instances have a `since` annotation. Should I add one, too? If so, which version should I add? 2. I tested this by recompiling ghc, running `ghc-stage2` interactively and typing `:info ST`, which printed the correct instances. I also ran `./validate`. Are there any other tests I shall perform for this kind of feature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 14:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 14:24:01 -0000 Subject: [GHC] #14109: GHC matches -- as a varsym when lexing a qvarsym Message-ID: <044.68208d60fba75e18bd381d8d54ed301c@haskell.org> #14109: GHC matches -- as a varsym when lexing a qvarsym -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- GHC seems only to exclude the line comment marker `--` when lexing a varsym and not a qvarsym. This can be observed in the following code {{{ module Demo where x Demo.-- y = (x,y) }}} Generating this surprising error message {{{ /Users/emertens/Desktop/Demo.hs:3:3: error: Qualified name in binding position: Demo.-- }}} and excludes this definition perhaps? {{{ example f = Just.-- comment f }}} Which might either have lexed as `Just` `.` `-- comment`, or it might have lexed as `Just.-` `-`, but it probably shouldn't be the case that it's a qvarsym. At a minimum, the Haskell Report specifically excludes `--` from the varsym rule, so it can't support the qvarsym rule match that it is now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 15:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 15:05:02 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.39feeee45c87d40eae3194f5045ffef2@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.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 RyanGlScott): 1. Yes, I'd add `@since: 4.11.0.0`, since that will be the next major version of `base`. 2. If it passes `./validate`, then I'd say it works! Do note that when you submit a patch via [https://phabricator.haskell.org/ Phabricator], the Harbormaster CI machines will also run `./validate` against your changes as an additional sanity-check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 15:32:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 15:32:41 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.41fa99f3ff9e4f857a0b0f59f73d89ff@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | 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 BoteboTsebo): * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 17:45:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 17:45:50 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.2c8a56412033fcf333419c2915c4675e@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Surely we could modify the usage analysis so code containing static forms is not considered dead. But I also wonder if deleting dead code this early is a good idea. If the user wants to optimize early compilation surely he could remove the code himself? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 18:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 18:30:27 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.9d10141a9023551b3e20faddda2f0076@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:7 and comment:8 seem out of scope for this ticket. This ticket is about type synonyms, not type families. comment:7 seems utterly out of reach. As explained in the [http://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1010&context=compsci_pubs paper], any type application that's not a declared parameter of a type is considered nominal. I think we'd need to overhaul the roles design to get that. comment:8, though, seems approachable, in two steps. Step 1: use data families, not type families. Step 2: #8177, which will allow non-nominal roles on data families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 18:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 18:50:30 -0000 Subject: [GHC] #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType In-Reply-To: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> References: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> Message-ID: <063.e92a74d941d6fb6cd943f8424d7de211@haskell.org> #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => TypeInType, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 18:51:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 18:51:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.6653f589ce58f60475066cbb14c49cd8@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13780 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we first need to decide on whether to keep the feature. Once that's settled, then we can look at the other issues (mostly pretty- printing) brought up here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 18:56:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 18:56:29 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313985=3A_GHC_8=2E0_regression=3A_?= =?utf-8?q?=E2=80=98k=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <050.713def54cc371cef366e72c06648a03c@haskell.org> References: <050.713def54cc371cef366e72c06648a03c@haskell.org> Message-ID: <065.f515b24f6b55a318b095cfbf0bf1530d@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13738 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I was hoping to nab this in a drive-by fix, but that didn't happen. The solution here, I think, is to put the kind variables in the implicit part of the `dfid_pats` field. (This is rather like what happens with ordinary data declarations.) Then, they'll be in scope during type-checking and we can discover that they're "floating". There's an interesting invariant that data instance declarations violate: every `Name` invented by the renamer must be bound precisely once. Indeed the "not in scope during type checking" error says the invariant is not upheld. It makes me want a linear type system, but we can't always get what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 19:21:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 19:21:52 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.b60b72d8841fade2302e9cecaf54368f@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D3843 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 19:22:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 19:22:53 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.c81823b71d3c099a6bb0cc848ca8b4a9@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I submitted a patch that makes the bindings containing static forms exported. Please, take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:08:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:08:06 -0000 Subject: [GHC] #14110: GHC Panic on over-saturated associated type family Message-ID: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> #14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If we over-saturate a type family {{{#!hs {-# Language TypeFamilies, ScopedTypeVariables, PolyKinds, DataKinds #-} import Data.Kind class R (c :: k -> Constraint) where type R_ (c :: k -> Constraint) :: k -> Type instance R Eq where type R_ Eq a = a -> a -> Bool }}} we get {{{ $ ghci -ignore-dot-ghci test.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTys a_a2qu[sk:1] a_a2qu[sk:1] -> Bool [] 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/types/Type.hs:809:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:18:17 -0000 Subject: [GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families In-Reply-To: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> References: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> Message-ID: <065.14a2cac79cb7d3ffe6bf6b58ed6f31ea@haskell.org> #14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: deriving 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:D3828 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"3f05e5f6becc2f7174898726b6f027105b12a780/ghc" 3f05e5f6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3f05e5f6becc2f7174898726b6f027105b12a780" Don't suppress unimplemented type family warnings with DeriveAnyClass Summary: For some asinine reason, we were suppressing warnings when deriving associated type family instances with `DeriveAnyClass`. That seems like a bad idea. Let's not do that. Along the way, I noticed that the error contexts associated with these newly emitted warnings were less than ideal, so I did some minor refactoring to improve the story there. Fixes #14094 Test Plan: ./validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14094 Differential Revision: https://phabricator.haskell.org/D3828 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:18:17 -0000 Subject: [GHC] #13823: Use NonEmpty lists in more places in the GHC API In-Reply-To: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> References: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> Message-ID: <065.aed0c52959e2e4d5146fa3b5bab98d60@haskell.org> #13823: Use NonEmpty lists in more places in the GHC API -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8782 | Differential Rev(s): Phab:D3823 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"7d699782bf6148c115a49b5f31ada9bd7c32a7d6/ghc" 7d69978/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7d699782bf6148c115a49b5f31ada9bd7c32a7d6" Use NonEmpty lists to represent lists of duplicate elements Summary: Three functions in `ListSetOps` which compute duplicate elements represent lists of duplicates of `[a]`. This is a really bad way to go about things, because these lists are guaranteed to always have at least one element (the "representative" of the duplicates), and several places in the GHC API call `head` (a partial function) on these lists of duplicates to retrieve the representative. This changes the representation of duplicates to `NonEmpty` lists instead, which allow for many partial uses of `head` to be made total. Fixes #13823. Test Plan: ./validate Reviewers: bgamari, austin, goldfire Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13823 Differential Revision: https://phabricator.haskell.org/D3823 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:18:17 -0000 Subject: [GHC] #14086: Empty case does not detect kinds In-Reply-To: <045.9d1433772cd165bffb28d64041403a96@haskell.org> References: <045.9d1433772cd165bffb28d64041403a96@haskell.org> Message-ID: <060.734427e2700df3a0227caac0391b1652@haskell.org> #14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | pmcheck/should_compile/T14086 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"4f1f9868ae79b5730c6aa14b05394d3f1d10a857/ghc" 4f1f9868/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4f1f9868ae79b5730c6aa14b05394d3f1d10a857" Change isClosedAlgType to be TYPE-aware, and rename it to pmIsClosedType Summary: In a267580e4ab37115dcc33f3b8a9af67b9364da12, I somewhat awkwardly inserted a special case for `TYPE` in the `EmptyCase` coverage checker. Instead of placing it there, @mpickering noted that `isClosedAlgType` would be a better fit for it. I do just that in this patch. I also renamed `isClosedAlgType` to `pmIsClosedType`, reflecting the fact that `TYPE` technically isn't an algebraic type (it's a primitive one), and that its behavior is pattern-match coverage checking-oriented. I also moved it to `Check`, which is a better home for this function than `Type`. Luckily, the only call sites for `isClosedAlgType` were in the pattern-match coverage checker anyways, so this change is simple enough. Test Plan: ./validate Reviewers: mpickering, austin, goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, mpickering GHC Trac Issues: #14086 Differential Revision: https://phabricator.haskell.org/D3830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:18:17 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.5b77c7e523f6eac04838b4c801a530c7@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0bb1e84034a12d7f700b48fca6710c01bd08f397/ghc" 0bb1e840/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0bb1e84034a12d7f700b48fca6710c01bd08f397" Expand type synonyms during role inference Summary: During role inference, we need to expand type synonyms, since oversaturated applications of type synonym tycons would otherwise have overly conservative roles inferred for its arguments. Fixes #14101. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #14101 Differential Revision: https://phabricator.haskell.org/D3838 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:20:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:20:19 -0000 Subject: [GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families In-Reply-To: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> References: <050.96bbfe24f50909dce22f27e786e00ec5@haskell.org> Message-ID: <065.f8aa3c4ecc99d7261e04185153906092@haskell.org> #14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | deriving/should_compile/T14094 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3828 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T14094 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:21:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:21:06 -0000 Subject: [GHC] #13823: Use NonEmpty lists in more places in the GHC API In-Reply-To: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> References: <050.a056cb71c10cdfa479dac95f5ba89eb4@haskell.org> Message-ID: <065.9ed5da6bc95aca5724d245ff8076bdc4@haskell.org> #13823: Use NonEmpty lists in more places in the GHC API -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8782 | Differential Rev(s): Phab:D3823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:25:42 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.3bd9f7f048840d60b37f7ebd3a0c5cf2@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"c6462ab02882779d7e33f2cac00cd89a9ac192f1/ghc" c6462ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6462ab02882779d7e33f2cac00cd89a9ac192f1" Add test for #14101 I forgot to do this in 0bb1e84034a12d7f700b48fca6710c01bd08f397. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 12 20:27:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Aug 2017 20:27:00 -0000 Subject: [GHC] #14101: Type synonyms can make roles too conservative In-Reply-To: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> References: <045.5d5aab6f527e0ee694b6bc74d2fd5ac5@haskell.org> Message-ID: <060.fea5fecd95864c214ea5e8da20aa90ac@haskell.org> #14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | roles/should_compile/T14101 Blocked By: | Blocking: Related Tickets: #8234 | Differential Rev(s): Phab:D3838 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => roles/should_compile/T14101 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 13 03:53:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Aug 2017 03:53:22 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.c950771fcf0ec648979fb877599d2a84@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 mrkgnao): Is there any activity on this? How difficult would it be to implement a basic proof-of-concept? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 13 16:44:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Aug 2017 16:44:59 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.fda75bc25da9c61411a36cce26cff406@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I skimmed the commits but nothing popped out. I guess it's bisect time... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 13 16:48:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Aug 2017 16:48:58 -0000 Subject: [GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules In-Reply-To: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> References: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> Message-ID: <058.63c9bf325a7608ccab430a7f271097a4@haskell.org> #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by ezyang): I would say, go for it. I suspect the weird behavior niteria describes was unintentional (or intentional, but only in the sense that it is easier to implement) and you can probably simplify it a lot. But do note that if the set of modules that gets retypechecked *changes*, that could introduce a bug. But there is some code in between getModLoop and the actual retypechecking... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 13 22:14:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Aug 2017 22:14:49 -0000 Subject: [GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules In-Reply-To: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> References: <043.67443c8e0af457e3e78fa2ff817b6e40@haskell.org> Message-ID: <058.5ec1b5807287287ccdf480f5ad3883ef@haskell.org> #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by duog): I think the current behaviour is correct. This is a complicated topic, so the explanation below is complicated, with lots of parenthesis! For the purposes of retypechecking, the loops are only used for their module names. There is one loop per hs-boot file. When we go to compile a hs file that has an hs-boot file (and therefore finishes a loop), the home package table has a ModDetails for this module (built from the hs-boot file), and all modules that transitively import that hs-boot file have been typechecked against that ModDetails. We retypecheck (i.e. rebuild their ModDetails from their interface) all those modules (but NOT the hs- boot modules) before typechecking the loop closer, then replace it's hs- boot ModDetails in the home package tables with it's full ModDetails. We then retypecheck the loop again, so that Ids in modules that imported the hs-boot module have their unfoldings attached. (although maybe this is wrong, see trac:14092) Note that it doesn't matter whether the modules we retypechecked were hs- boot interfaces or full hs interfaces. I think this is the key point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 00:19:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 00:19:18 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families Message-ID: <045.61bc63eee0a790503467c9479892f97e@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 the following small example {{{ {-# LANGUAGE MagicHash, UnboxedSums, NoImplicitPrelude #-} {-# LANGUAGE TypeFamilies #-} -- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs ,ExplicitNamespaces#-} {-# LANGUAGE UnboxedTuples #-} module Data.Unboxed.Maybe where import GHC.Exts import GHC.Types import Prelude (undefined) import Data.Void data family Maybe(x :: TYPE (r :: RuntimeRep)) data instance Maybe (a :: * ) where MaybeSum :: (# a | (# #) #) -> Maybe a data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe x }}} and then i get the error (made much saner to read by use of printing explicit kinds) {{{ Prelude> :r [1 of 1] Compiling Data.Unboxed.Maybe ( src/Data/Unboxed/Maybe.hs, interpreted ) src/Data/Unboxed/Maybe.hs:22:3: error: • Data constructor ‘MaybeSumU’ returns type ‘Maybe 'LiftedRep x’ instead of an instance of its parent type ‘Maybe 'UnliftedRep x’ • In the definition of data constructor ‘MaybeSumU’ In the data instance declaration for ‘Maybe’ | 22 | MaybeSumU :: (# x | (# #) #) -> Maybe x }}} this is a) a case where printing runtime reps makes things easier to debug :) b) a very confusing type error since the data instance clearly says "x :: TYPE 'UnliftedRep " is there something i'm overlooking, or is this a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 00:20:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 00:20:37 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.4a9ae28b22e69f0f34088153bd951428@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): remarkably, if i add the type annotation, this works! (but it still seems like a bug in inference) {{{ data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe (x :: TYPE 'UnliftedRep) }}} it seems kinda redundant ?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 00:41:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 00:41:19 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) Message-ID: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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'm trying to define my own fancy strict maybe types, and so i've written some pattern synonyms to wrap them up. imagine my surprise when i find i can write bang patterns on the *right* hand side, but not the left hand! {{{ data MyMaybe a = JustC a | NothingC pattern MyJust :: a -> MyMaybe a -- pattern MyJust !a = JustC a -- this fails pattern MyJust a = JustC !a -- this is fine }}} is this deliberate or a leakage of how desugaring works? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 01:23:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 01:23:56 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.8a1fb82473ddaeff99117de5051b5e7e@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies Comment: One important to note is that in this data instance: {{{#!hs data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe x }}} The `x` in `data instance Maybe (x :: TYPE 'UnliftedRep)` does //not// scope over the constructors (this is a quirk of GADTs). Therefore, the kind of `x` in `data instance Maybe (x :: TYPE 'UnliftedRep)` doesn't necessarily determine the kind of `x` in `MaybeSumU`'s type signature (as the `x` in `(# x | (# #) #) -> Maybe x` is bound by an implicit `forall x`). That being said, I'm still surprised this doesn't typecheck. Here's a simpler example of this bug that doesn't involve levity polymorphism or `TypeInType`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family F (a :: k) data instance F (a :: Bool) where MkF :: F a }}} {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170807: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:3: error: • Data constructor ‘MkF’ returns type ‘F a’ instead of an instance of its parent type ‘F a’ • In the definition of data constructor ‘MkF’ In the data instance declaration for ‘F’ | 9 | MkF :: F a | ^ Failed, 0 modules loaded. λ> :set -fprint-explicit-kinds λ> :r [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:3: error: • Data constructor ‘MkF’ returns type ‘F k a’ instead of an instance of its parent type ‘F Bool a’ • In the definition of data constructor ‘MkF’ In the data instance declaration for ‘F’ | 9 | MkF :: F a | ^ Failed, 0 modules loaded. }}} Here's we can see that since `a` appears unadorned in `F a`, its kind seems to be inferred as `k` (as given from the data family definition), although we'd much rather have it inferred as `Bool`, which you'd expect from the instance head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 01:46:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 01:46:31 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.f64b1f2633ed6e1e21a28f798ca4402f@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternSynonyms Comment: I'm not surprised that putting bang patterns on the left-hand side of a pattern synonyms doesn't work. After all, the left-hand side simply binds pattern variables. No more, no less. I am surprised, however, that putting bang patterns on the //right//-hand side does work. Especially since the right-hand sides of simply bidirectional pattern synonyms are supposed to be valid expressions, and `JustC !a` certainly doesn't feel like one. Curiously, the users' guide documentation is quite silent about the relationship between simply bidirectional pattern synonyms and bang patterns. To fix this quandary, we could either: 1. Disallow bang patterns entirely on the right-hand sides of simply bidirectional pattern synonyms (like we do with wildcard patterns and view patterns). 2. Document the current behavior as expected. `JustC !a` is bit strange- looking from an expression standpoint, but at the same time, it does work and accomplishes a useful task, so perhaps we shouldn't throw the baby out with the bathwater. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 01:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 01:57:44 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.6e6fd741c8b0118e82b7d387dbfb38c0@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): In this case the error is made even more pernicious by the default suppression of Levity arguments, but yeah, i see how its indeed the same issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 07:53:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 07:53:44 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.1c027b8514c7a080a114cd14d3930201@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'm not familiar with `libuv`, but just to list the concerns I would have about replacing the IO manager: * Performance: the current IO manager was pretty heavily tuned and optimised when it was developed, the benchmarks and results are described in the Mio paper. I'd like to see comparative results showing that libuv is at least as fast for the same benchmarks before we consider switching. Some performance issues can be subtle (e.g. unsafe FFI calls that take too long, or mutable data structures that affect generational GC performance), so even if the benchmarks are good we'd need to examine the code quite carefully. * Dependencies (as @bgamari pointed out) can be problematic. How would we handle the dependency? Import it into the tree (as with libffi), as a submodule (as with packages), or require it to be installed and test for it in configure (as with LLVM / gmp, but IIRC we're thinking of changing this for LLVM)? * Correctness: there is a history of subtle bugs in the IO manager and its interface with the rest of the IO library. I don't know how best to avoid introducing new problems other than the regression test suite, but it's worth mentioning that this is an area we need to be especially careful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 11:47:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 11:47:45 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.af6117a8b976b5eabd8cdf05208e95e6@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.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): Phab:D3845 Wiki Page: | -------------------------------------+------------------------------------- Changes (by plato): * status: new => patch * differential: => Phab:D3845 Comment: I added a differential on phabricator. Everything seems to work on Windows, Linux, and OSX. See here: https://phabricator.haskell.org/B17099 I hope I got the "Differential Rev(s)" format right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 13:13:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 13:13:44 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros Message-ID: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a program which doesn't typecheck: {{{#!hs {-# LANGUAGE CPP #-} module Bug where #define FOO putStrLn 4 main :: IO () main = FOO }}} The error message it gives looks kind of strange, however: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:17: error: • No instance for (Num String) arising from the literal ‘4’ • In the first argument of ‘putStrLn’, namely ‘4’ In the expression: putStrLn 4 In an equation for ‘main’: main = putStrLn 4 | 7 | main = FOO | ^ }}} That caret seems to be pointing as if `FOO` had been replaced by `putStrLn 4` in the diagnostic, but since it hadn't, it just points off into space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 13:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 13:31:49 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.478cd5209385a33c1887cf937f70ba13@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I seem to recall this behavior being a deliberate design decision -- GADT constructor types stand alone. There was a long ticket with commentary and deliberations. Sadly, I can't find it, and 10 minutes of `git blame`-chasing in the area of code that should have been affected didn't find anything either. Perhaps SPJ remembers more. This kind of problem should always succumb to a kind annotation somewhere, but I agree that it's unfortunate and repetitive to put the annotation in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 13:50:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 13:50:42 -0000 Subject: [GHC] #14110: GHC Panic on over-saturated associated type family In-Reply-To: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> References: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> Message-ID: <066.f6df1b7f42ad368b0b0b79cfff6806a4@haskell.org> #14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Already fixed in HEAD, most likely with my recent raft of changes. I'm not in a good state to add the test-case though -- could someone else? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 13:58:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 13:58:17 -0000 Subject: [GHC] #14110: GHC Panic on over-saturated associated type family In-Reply-To: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> References: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> Message-ID: <066.7544b6c9de523caa7066cc36bea15c19@haskell.org> #14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: (none) => Iceland_jack Comment: I'll do it when I get home -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 16:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 16:30:27 -0000 Subject: [GHC] #14108: GHCi doesn't remember let-less function declarations with -fobject-code In-Reply-To: <050.c25f430b23baa32d72b0e3ee9006d0fb@haskell.org> References: <050.c25f430b23baa32d72b0e3ee9006d0fb@haskell.org> Message-ID: <065.2024e2096c9e5cca197bbed10b046475@haskell.org> #14108: GHCi doesn't remember let-less function declarations with -fobject-code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I believe I've identified the culprit. It turns out that the binding for `foo2` is discarded entirely during desugaring—in particular, the function [http://git.haskell.org/ghc.git/blob/c6462ab02882779d7e33f2cac00cd89a9ac192f1:/compiler/deSugar/Desugar.hs#l280 addExportFlagsAndRules] is to blame. Normally, the `HscTarget` argument is `HscInterpreted`, on which `targetRetainsAllBindings` returns `True`, causing `addExportFlagsAndRules` to set the `foo2` `Id` as exported. However, when the `HscTarget` argument is, say, `HscAsm` (which can happen when `-fobject-code` is enabled), then `targetRetainsAllBindings` returns `False`. As a result, `addExportFlagsAndRules` checks if the `foo2` `Id` is contained in either the `keep_alive` or `exported` sets—but in GHCi, both of those are always empty, so `foo2` isn't marked as exported, causing the desugarer to discard it later. Bummer. This makes me believe that we should alter `addExportFlagsAndRules` so that it always marks local bindings as exported when we're in an interactive module (i.e., in GHCi). I'll experiment with this approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 17:29:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 17:29:22 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.791f32b0626bc2dfb15e1bf4c1dddb0e@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 carter): well, my first question is: how do i validate that this bang pattern? i've looked at the core this generates, and it looks like im only getting strictness when i'm matching on the `Just` and not when i'm using it as a constructor! or maybe i'm not reading the Just constructor code correclty {{{ -- RHS size: {terms: 5, types: 9, coercions: 0, joins: 0/0} $bJust1_r1wL :: forall a. a -> Data.Unboxed.Maybe.R:MaybeLiftedRepa a [GblId, Arity=1, Caf=NoCafRefs] $bJust1_r1wL = \ (@ a_a1zx) (a1_a1xs :: a_a1zx) -> break<5>(a1_a1xs) Data.Unboxed.Maybe.MaybeSum @ a_a1zx (GHC.Prim.(#_|#) @ 'LiftedRep @ ('TupleRep '[]) @ a_a1zx @ (# #) a1_a1xs) }}} plus the casing encoding {{{ -- RHS size: {terms: 17, types: 31, coercions: 2, joins: 0/0} Data.Unboxed.Maybe.$mJust :: forall (r :: TYPE rep) a. Maybe a -> (a -> r) -> (Void# -> r) -> r [GblId, Arity=3] Data.Unboxed.Maybe.$mJust = \ (@ (rep_a1zm :: RuntimeRep)) (@ (r_a1zn :: TYPE rep_a1zm)) (@ a_a1xr) (scrut_a1zo :: Maybe a_a1xr) (cont_a1zp :: a_a1xr -> r_a1zn) _ [Occ=Dead] -> break<2>(scrut_a1zo,cont_a1zp) case scrut_a1zo `cast` (Data.Unboxed.Maybe.D:R:MaybeLiftedRepa0[0] _N :: (Maybe a_a1xr :: *) ~R# (Data.Unboxed.Maybe.R:MaybeLiftedRepa a_a1xr :: *)) of { MaybeSum ds_d1zX -> case ds_d1zX of { (#_|#) a1_X1y7 -> cont_a1zp a1_X1y7; (#|_#) ipv_s1A5 -> Control.Exception.Base.patError @ rep_a1zm @ r_a1zn "src/Data/Unboxed/Maybe.hs:37:19-37|case"# } } }}} latter seems like the "usual" eliminator form, as far as I can tell. I am confused about the exception throwing element of pattern synonyms, is that generally case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 17:59:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 17:59:38 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.6383446c10ad51e2e1097346fab22dda@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > But I also wonder if deleting dead code this early is a good idea. I don't see why not. The less code we hand to the simplifier the better. > I submitted a patch that makes the bindings containing static forms exported. Please, take a look. I don't think Phab:D3843 is the right solution here. Not only does it require that we sweep the entire Core program looking for statics (and consequently fairly expensive), but it's quite indirect. Teaching the occurrence analysis about statics sounds somewhat sensible; afterall, static forms essentially allow the user to refer to static subexpression from any context, regardless of scoping. Declaring such a subexpressions as dead is obviously wrong. One way to teach the analyser this would be to add a "contains static form" flag to `UsageDetails`. Then when analysing a binding check the flag of the analysis result of the RHS; if set, `markMany` the binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 19:32:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 19:32:46 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.baff7c95a0725a973a6a61e02a4ab2ca@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Looks fine to me. Would be good to know if anyone objects before going through the trouble of implementing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 19:34:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 19:34:21 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.1052049c717136618570999ea6291a98@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): The issue is similar to #13388 but, unlike hsc2hs, my understanding is that cpp doesn't fall under the purview of the GHC project (yet?), so it's not possible to coerce it into outputting column information. One could prevent the caret from pointing past the actual line, but that only masks the problem under certain circumstances. Another option is to simply not show the caret if cpp is involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 20:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 20:20:55 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.da173070aa974e244e77579c23bac7fc@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D3848 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 20:28:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 20:28:49 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.5ba86eabc9fa5e700c322a1b31475129@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): I just finished bisecting, the commit that removes the panic is 69d9081d9fa3ff36fda36e4e11ef7e8f946ecf2a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 20:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 20:40:26 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.c4eb66afac7762ab208f28eabfa69efb@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mpickering (added) Comment: Ah, now this is interesting. You've noted that there is a semantic difference between implicitly bidirectional pattern synonyms with bang patterns and explicitly bidirectional synonyms with bang patterns. Consider these definitions: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE PatternSynonyms #-} module Bug where data Pair a = MkPair a a pattern MyPair1 x y <- MkPair !x !y where MyPair1 !x !y = MkPair x y pattern MyPair2 x y = MkPair !x !y }}} The expression: {{{#!hs let MkPair x y = MyPair1 "a" undefined in putStrLn x }}} throws an exception. However, the expression: {{{#!hs let MkPair x y = MyPair2 "a" undefined in putStrLn x }}} simply prints `a`. This asymmetry does feel quite unsavory to me. While we could just disallow `pattern MyPair2 x y = MkPair !x !y` entirely to avoid this, it doesn't feel like a very satisfactory solution, since defining an implicitly bidirectional pattern synonym with bang patterns feels like something useful that GHC should be able to do. So the question becomes: should we change the semantics of `pattern MyPair2 x y = MkPair !x !y` so that the `MyPair2` builder expression becomes strict in its arguments? But it's a bit weird to have bang patterns on the RHS of something determine the strictness of its binding sites on the LHS. Alternatively, we could change the syntax of implicitly bidirectional pattern synonyms to allow `pattern MyPair2 !x !y = ...`. This would bring it more in-line with explicitly bidirectional pattern synonyms, where there are two sets of binding sites: the pattern variable binders in `pattern MyPair1 x y`, as well as the builder expression's bound variables in `where MyPair1 !x !y`. Notice that you can only give bang patterns to the latter set of bound variables. Implicitly bidirectional pattern synonyms combine these two sets of bound variables into one, so perhaps we should allow bang patterns on the LHS of implicit synonyms to bring it up to par with explicit ones. An interesting consequence of this second design choice is that you could have varying combinations of strictness. For instance, all four of these could co-exist: {{{#!hs pattern Foo1 x = MkFoo1 x -- Lazy in builder and pattern pattern Foo2 !x = MkFoo2 x -- Strict in builder, lazy in pattern pattern Foo3 x = MkFoo3 !x -- Lazy in builder, strict in pattern pattern Foo4 !x = MkFoo4 !x -- Strict in builder and pattern }}} Perhaps this is the better solution, since now implicitly bidirectional pattern synonyms would be equally as expressive as explicit ones vis à vis strictness. The downside is that we'd be endorsing a design that allows RHSes that aren't valid expressions, but I think this is a small price to pay for the increased expressiveness. I'm cc'ing Matthew, since I'd be curious to hear what his thoughts are on the matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 22:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 22:24:34 -0000 Subject: [GHC] #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS Message-ID: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- These might be two separate bugs, but they're similar enough that I'll bundle them under the same ticket. If you take a pattern variable bound on the LHS of a unidirectional pattern synonym and use it multiple locations on the RHS, then GHC accepts it, surprisingly: {{{#!hs pattern Foo a <- (a,a) }}} What does `Foo` do? As it turns out, the right-most occurrence of `a` in the RHS seems to take precedence: {{{ λ> :i Foo pattern Foo :: b -> (a, b) -- Defined at :12:1 λ> case ('a', 'b') of Foo x -> x 'b' }}} I expect the definition of `Foo` to error. When duplicate pattern variables are used in the RHS of an implicitly bidirectional pattern synonym, then it does error. However, the error message is quite misleading: {{{ λ> pattern Foo a = (a,a) :16:17: error: Invalid right-hand side of bidirectional pattern synonym ‘Foo’: ‘a’ is not bound by the LHS of the pattern synonym RHS pattern: (a, a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 22:32:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 22:32:24 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.7cb34369fc7db0337718a90899d0aeda@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:1 Rufflewind]: > One could prevent the caret from pointing past the actual line, but that only masks the problem under certain circumstances. What do you mean by "masks the problem"? I'd be content with a solution similar to how `gcc` handles CPP macros when displaying carets: {{{#!c #define FOO return "wat"; int main() { FOO } }}} {{{ $ gcc wat.c wat.c: In function ‘main’: wat.c:1:20: warning: return makes integer from pointer without a cast [-Wint-conversion] #define FOO return "wat"; ^ wat.c:4:3: note: in expansion of macro ‘FOO’ FOO ^~~ }}} But I'm not familiar with how tightly integrated `gcc` and `cpp` are (as opposed to GHC and `cpp`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 23:00:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 23:00:31 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.ecdb55e653d75b93a256dc109887a8d4@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): > What do you mean by "masks the problem"? As in it will only hide the problem when the column number is obviously wrong (exceeds the length of the original line). > I'd be content with a solution similar to how `gcc` handles CPP macros when displaying carets: I think gcc has some internal magic with its cpp (and same for clang). If you compile using `gcc -E wat.c | gcc -x c -` you will run into exactly the same bug here. {{{ wat.c: In function ‘main’: wat.c:4:12: warning: return makes integer from pointer without a cast [-Wint-conversion] FOO ^ }}} cpp simply does not provide ghc with adequate line information to determine the correct column. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 14 23:54:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Aug 2017 23:54:11 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.4d2416ffa235fa5be8a73a266d393942@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 Rufflewind]: > I think gcc has some internal magic with its cpp (and same for clang). If you compile using `gcc -E wat.c | gcc -x c -` you will run into exactly the same bug here. > > {{{ > wat.c: In function ‘main’: > wat.c:4:12: warning: return makes integer from pointer without a cast [-Wint-conversion] > FOO > ^ > }}} > > cpp simply does not provide ghc with adequate line information to determine the correct column. Urk, I was afraid of that. Well, if there isn't a reliable way to obtain this information, I suppose there isn't much we can do here. You mentioned that we could suppress the caret if CPP is involved, although I don't know if it's possible to reliably detect that. Alternatively, we could not do anything and close this as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 00:03:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 00:03:24 -0000 Subject: [GHC] #14108: GHCi doesn't remember let-less function declarations with -fobject-code In-Reply-To: <050.c25f430b23baa32d72b0e3ee9006d0fb@haskell.org> References: <050.c25f430b23baa32d72b0e3ee9006d0fb@haskell.org> Message-ID: <065.71b87c5926d011f39390723ce99aa805@haskell.org> #14108: GHCi doesn't remember let-less function declarations with -fobject-code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12091 Comment: Well whaddya know, this is a duplicate of #12091. Luckily, I already have a patch whipped up for this, so I'll just change the ticket number :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 00:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 00:10:09 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.8544f5be95b52cb3b99b4ab40e01b088@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: GHCi | 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: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3849 * related: #7253 => #7253, #14108 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 00:18:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 00:18:37 -0000 Subject: [GHC] #14071: Porting GHC to another function programming language. In-Reply-To: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> References: <044.15db87cc99bd673c808f39120fa34d52@haskell.org> Message-ID: <059.d956b64254aa76a23fc9f9fe8f91a0e7@haskell.org> #14071: Porting GHC to another function programming language. -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: I think what this ticket suggests essentially amounts to writing a new compiler. Do feel free to work on this, but I don't think this is a GHC issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:35:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:35:08 -0000 Subject: [GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks In-Reply-To: <049.64e07177e9110058c04a019d46370d44@haskell.org> References: <049.64e07177e9110058c04a019d46370d44@haskell.org> Message-ID: <064.624fd23f73e0269b34ee6638875f61b0@haskell.org> #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: 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:"c7e6c9074511f74f73eaa3b41051afc94aeb653a/nofib" c7e6c90/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="c7e6c9074511f74f73eaa3b41051afc94aeb653a" Add State monad benchmarks by Andras Kovacs Summary: They are originally from https://github.com/AndrasKovacs/misc- stuff/blob/master/haskell/Eff/EffBench.hs They show interesting interactions with call arity, spec constr and SAT. Reviewers: O26 nofib, michalt, simonpj, bgamari Reviewed By: bgamari Subscribers: RyanGlScott GHC Trac Issues: #13892 Differential Revision: https://phabricator.haskell.org/D3683 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:35:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:35:08 -0000 Subject: [GHC] #13711: uname: illegal option -- o when running make clean in nofib In-Reply-To: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> References: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> Message-ID: <064.a1c3640d1a1c7403039c4fd72f4ff03e@haskell.org> #13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3594 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7debffc19e17ceec7a5fc4bde9aa9780847dda17/nofib" 7debffc/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="7debffc19e17ceec7a5fc4bde9aa9780847dda17" Don't use uname -o Summary: It's not required by the POSIX specification and OS X doesn't support it; instead use uname -s. Test Plan: V Reviewers: O26 nofib, michalt, mpickering Reviewed By: O26 nofib, michalt, mpickering Subscribers: mpickering GHC Trac Issues: #13711 Differential Revision: https://phabricator.haskell.org/D3594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:35:28 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.e5bde6ba188c4bb403415a8ab88e0658@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: GHCi | 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: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ddb870bf7055ccc8ff8b86c161f31aad81d01add/ghc" ddb870b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ddb870bf7055ccc8ff8b86c161f31aad81d01add" Don't drop GHCi-defined functions with -fobject-code enabled The desugarer was using `targetRetainsAllBindings` as a litmus test for determining if a function was defined in interactive mode (and thus should be exported). However, there is a corner case where one can be in interactive mode and have `targetRetainsAllBindings` return `False`: if `-fobject-code` is enabled (since the target will no longer be `HscInteractive`). In such a scenario, we should fall back on a different test for determining if we are in a GHCi session. I chose to use `isInteractiveModule`, which appears to do the trick. Test Plan: make test TEST=T12091 Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12091 Differential Revision: https://phabricator.haskell.org/D3849 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:35:28 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.7a649d21f1ccb6a083b791fef78db65a@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.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): Phab:D3845 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"441c52de0621ac68a2248cf691b4de31fba48a34/ghc" 441c52d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="441c52de0621ac68a2248cf691b4de31fba48a34" Add Semigroup/Monoid instances to ST monad Fixes #14107. Signed-off-by: Philipp Middendorf Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: bgamari Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #14107 Differential Revision: https://phabricator.haskell.org/D3845 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:35:28 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.4f55e4a1901669e69ccf4b82d2a372d8@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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:D3807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ad7b945257ea262e3f6f46daa4ff3e451aeeae0b/ghc" ad7b945/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad7b945257ea262e3f6f46daa4ff3e451aeeae0b" Fix #14060 by more conservatively annotating TH-reified types Before, TH was quite generous in applying kind annotations to reified type constructors whose result kind happened to mention type variables. This could result in agonizingly large reified types, so this patch aims to quell this a bit by adopting a more nuanced algorithm for determining when a tycon application deserves a kind annotation. This implements the algorithm laid out in https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated `Note [Kind annotations on TyConApps]` to reflect the new wisdom. Essentially, instead of only checking if the result kind contains free variables, we also check if any of those variables do not appear free in injective positions in the argument kinds—only then do we put on a kind annotation. Bumps `haddock` submodule. Test Plan: make test TEST=T14060 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #14060 Differential Revision: https://phabricator.haskell.org/D3807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 01:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 01:37:46 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.4b00cc5b9c3077b13f1b688ce0793cc2@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In that case it would be good to get Simon's opinion before proceeding. Simon, what do you think about comment:7? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 02:00:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 02:00:18 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.b36adfbe64ea898297d3f52f7818340d@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): I feel that suppressing carets for CPPed files could hurt usability in the cases where the bug doesn't occur. I'd say this should be filed under: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp If that proposal makes progress, then we could resolve this much more easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 02:02:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 02:02:40 -0000 Subject: [GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros In-Reply-To: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> References: <050.0257fc2113dbcfbe27f9b1429e97b726@haskell.org> Message-ID: <065.8928350b295bc086c8f735b100dbc218@haskell.org> #14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: cpp 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 RyanGlScott): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 02:10:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 02:10:30 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.77133d6d6217e3d60bd9cc7928b3465f@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new * owner: RyanGlScott => (none) * differential: Phab:D3831 => Comment: Richard and I decided that the approach taken in Phab:D3831 wasn't the best course of action. Although it would allow exotic GADT constructor type signatures like `Ord a => Eq a => a -> F a`, it would come at a steep price: GHC would normalize the type signature to `(Ord a, Eq a) => a -> F a` behind the scenes, so you'd no longer see the type you originally wrote when you queried it with `:type +v`. For this reason, I've decided to try to improve the current error message instead, which doesn't make it very clear what the underlying problem is (nor how to fix it). Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 02:44:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 02:44:35 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.2b7230667803a8fca8071e20cc26bc79@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Phab:D3851 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3851 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 02:45:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 02:45:43 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.9b63ae29487d2a73ac7bd4c1a9d88ad6@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): OK, that makes sense, but disappointingly, it may mean the underlying bug is still lurking, but under a different repro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 08:28:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 08:28:21 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.9d18bb8ab089b73051545c7e7ebe3ace@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by mpickering): The perf results don't look very promising for this branch. https://perf.haskell.org/ghc/#compare/fefcbfa86b73517d5002366d0703ce694c6d228d/599aa0616211e42cf642a177515d5f8bee431eeb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 09:32:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 09:32:35 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.47c18333ed823a69774e494a9894d601@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I share the same concerns above, so my experiment is still under going, so far the results are: the libuv I/O system's performance is slightly better(~10%), and allocate slightly less(~10%~20%), the GC pause is much lower(~30%). we test it under different load, we also did a test on a 36-core 512G RAM server accorading to the MIO paper. We(I and a student in BHU who used to work as an intern under my supervision) are planning to write a paper about this new I/O system design, collecting all the result above, and do some analysis. Since this year's HIW submission is closed already. We're looking forward to submit this paper in next year's HIW. So we still have plenty of time to polish our work. We would much appreciate if someone can recommend some places to submit a paper like this ; ) If we somehow choose to use libuv in GHC, the libuv dependency should be managed like libffi IMO, it's easy to build and we should ship it with GHC to help user get started(just like node.js). As for correctness, i think switch to libuv is actually helpful to reduce bugs since we don't need to interface different OS event backend. A regression test suite is definitely helpful, i'll try to make one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 09:48:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 09:48:48 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO Message-ID: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When ghc 8.2.1 compiled using DYNAMIC_GHC_PROGRAMS=NO attemps at using TH results in all sorts of exciting errors: source files: {{{ % cat A.hs {-# LANGUAGE TemplateHaskell #-} module Numeric.Sum where import B b }}} this file makes little sense, but it was segfaulting when it had more code as well {{{ % cat B.hs {-# LANGUAGE TemplateHaskellQuotes #-} module B where import Language.Haskell.TH b :: DecsQ b = return [ InstanceD Nothing [] (ConT ''Show `AppT` undefined) [] ] }}} Let's try running it a few times - note illegal hardware instruction {{{ % ghc -O2 A.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: illegal hardware instruction ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 11:43:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 11:43:38 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions In-Reply-To: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> References: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> Message-ID: <061.d681edfe2a539a59b2b6bb307025cdc3@haskell.org> #13911: GHC RTS VEH swallowing exceptions -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 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 Phyx-): * failure: Runtime crash => Incorrect result at runtime * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 8.4.1 Comment: We do want to handle unhandled exceptions internally because of the interpreter. Code faulting during runtime linker handling leaves the application in an indeterminate state. Especially if it happened during e.g. processing of relocation. The problem with `SetUnhandledExceptionFilter` is that it replaces any existing top level filter. So it again interacts badly with your interop scenario, though maybe to a lesser extend. I think using a `VCH` instead of a `VEH` should work since those would be the last to be called instead of the first. I'll get this changed for `8.4` when I make the crash output more useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 11:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 11:47:17 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.c129dd378a6cbe62f239dde518d5bd6f@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 Phyx-): Thanks for the report, which operating system are you on? switching `DYNAMIC_GHC_PROGRAMS=NO` introduces a large platform variant as each platform has it's own linker so it would be useful to know Which one it is :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 11:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 11:59:10 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.a2cbb5141f7338190911eef18baa14c0@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 pacak): Ubuntu 16.04.2 LTS I think it segfaults before linking, not sure. Original was segfaulting when compiling 1 of 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:16:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:16:41 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.df13a80be7eb7b2c9378276c7dceadec@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 Phyx-): * os: Unknown/Multiple => Linux * component: Compiler => Runtime System (Linker) Comment: Thanks. The act of running TH code already involves linking, just using the runtime linker instead of the system linker (which you see you visual output for). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:30:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:30:16 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.fd82726c5a50af3195c4dff1ce044458@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): So that kind of linking... I see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:50:30 -0000 Subject: [GHC] #13711: uname: illegal option -- o when running make clean in nofib In-Reply-To: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> References: <049.88cdc224335cf1541b7c50c6988ce9ec@haskell.org> Message-ID: <064.5172283290a9cae6d0eb52fa9b160bd8@haskell.org> #13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:51:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:51:01 -0000 Subject: [GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks In-Reply-To: <049.64e07177e9110058c04a019d46370d44@haskell.org> References: <049.64e07177e9110058c04a019d46370d44@haskell.org> Message-ID: <064.f73d8bb61f1a049a7a54d62717a7f916@haskell.org> #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.0.1 suite | 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 * milestone: => 8.4.1 Comment: These are now in nofib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:51:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:51:17 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.689e7974cabcb8bdb8addfa847d971ad@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | 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:D3807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:51:40 -0000 Subject: [GHC] #14107: Implement Semigroup and Monoid instances for the ST monad In-Reply-To: <044.6302be4678eb9c4717101ae155816826@haskell.org> References: <044.6302be4678eb9c4717101ae155816826@haskell.org> Message-ID: <059.ce64e4709015328b1764a425cdb3672a@haskell.org> #14107: Implement Semigroup and Monoid instances for the ST monad -------------------------------------+------------------------------------- Reporter: plato | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.2.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:D3845 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks plato! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:52:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:52:33 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.92e1b1cfe0d846d1afeb66a988c8366a@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #14108 | Differential Rev(s): Phab:D3849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 12:53:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 12:53:00 -0000 Subject: [GHC] #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks In-Reply-To: <049.64e07177e9110058c04a019d46370d44@haskell.org> References: <049.64e07177e9110058c04a019d46370d44@haskell.org> Message-ID: <064.f0230d6e3ba6dc3b2a19b8abf8daca49@haskell.org> #13892: Add some benchmarks to nofib from Andras Kovac's Eff benchmarks -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.0.1 suite | Resolution: | Keywords: 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: closed => new * owner: mpickering => (none) * resolution: fixed => Comment: There are still more that can be added. The state monad ones were just the easiest to add initially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 13:44:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 13:44:10 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.c3d93b055fe6bec6745f0133f7987d68@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | 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:D3751, Wiki Page: | Phab:D3854 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D3751 => Phab:D3751, Phab:D3854 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 13:45:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 13:45:04 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.4712d190a23cd7d956cd589dffcdf0f4@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari Comment: I'm now looking at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 13:52:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 13:52:41 -0000 Subject: [GHC] #14116: Core lint error while compiling master Message-ID: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> #14116: Core lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 compiling e054c5f06451def4437d9d770ae156f034796c59 with the following `build.mk`, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcStage2HcOpts += -eventlog GhcStage1HcOpts += -eventlog GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} I encountered this Core lint failure while compiling `PprColour`, {{{ stgEqType: unequal PprColour [Char] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** compiler/utils/PprColour.hs:62:1: warning: [RHS of defaultScheme :: Scheme] In a RHS constructor application, con type doesn't match arg types: Constructor type: PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> Scheme Arg types: [Char] PprColour String String String String *** Offending Program *** ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 13:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 13:54:39 -0000 Subject: [GHC] #14116: Core lint error while compiling master In-Reply-To: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> References: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> Message-ID: <061.a33f74e1165509327d3dbab9c2b93f13@haskell.org> #14116: Core lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a relevant excerpt from the core program, {{{#!hs defaultScheme4_r2S1 :: String [GblId] = \u [] src src src src src src mappend $fMonoid[] colBold colBlueFg; defaultScheme :: Scheme [GblId, Unf=OtherCon []] = NO_CCS Scheme! [$cmempty_r2Rw colBold defaultScheme1_r2RY defaultScheme2_r2RZ defaultScheme3_r2S0 defaultScheme4_r2S1]; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 13:59:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 13:59:05 -0000 Subject: [GHC] #14116: STG lint error while compiling master (was: Core lint error while compiling master) In-Reply-To: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> References: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> Message-ID: <061.405dc4ed9f0b89bb01a5567ef4a607ec@haskell.org> #14116: STG lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > While compiling e054c5f06451def4437d9d770ae156f034796c59 with the > following `build.mk`, > {{{ > BuildFlavour = devel2 > include mk/flavours/$(BuildFlavour).mk > > GhcStage2HcOpts += -eventlog > GhcStage1HcOpts += -eventlog > > GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint > -dcmm-lint > GhcRtsHcOpts += -g3 > GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint > -dcmm-lint > }}} > > I encountered this Core lint failure while compiling `PprColour`, > {{{ > stgEqType: unequal > PprColour > [Char] > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.3.20170815 for x86_64-unknown-linux): > *** Stg Lint ErrMsgs: in Stg2Stg *** > compiler/utils/PprColour.hs:62:1: warning: > [RHS of defaultScheme :: Scheme] > In a RHS constructor application, con type doesn't match arg types: > Constructor type: > PprColour > -> PprColour > -> PprColour > -> PprColour > -> PprColour > -> PprColour > -> Scheme > Arg types: > [Char] > PprColour > String > String > String > String > *** Offending Program *** > ... > }}} New description: While compiling e054c5f06451def4437d9d770ae156f034796c59 with the following `build.mk`, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcStage2HcOpts += -eventlog GhcStage1HcOpts += -eventlog GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} I encountered this STG lint failure while compiling `PprColour`, {{{ stgEqType: unequal PprColour [Char] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** compiler/utils/PprColour.hs:62:1: warning: [RHS of defaultScheme :: Scheme] In a RHS constructor application, con type doesn't match arg types: Constructor type: PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> Scheme Arg types: [Char] PprColour String String String String *** Offending Program *** ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 14:12:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 14:12:49 -0000 Subject: [GHC] #14116: STG lint error while compiling master In-Reply-To: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> References: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> Message-ID: <061.01f2320b6faf98db4b2cd3cf7a4f0c55@haskell.org> #14116: STG lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like this is really just another bug in STG lint: we fail to look through newtypes despite the fact that we have thrown away casts during Core-to-STG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 14:46:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 14:46:01 -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.58fba09ac9fc89684f8a3243e925ad42@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 14:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 14:47:53 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.43757e36f7041c3f82ea63a7704098a4@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | 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 goldfire): * status: new => closed * resolution: => worksforme Comment: The program below, taken from the original ticket description, compiles on HEAD and 8.2.1: {{{#!hs {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies #-} module Bug where import Data.Kind data Sig a = Full a | a :-> Sig a data AST :: (Sig a -> Type) -> (Sig a -> Type) -- ASTF :: (Sig a -> Type) -> (a -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} There's been a lot of other chatter on this ticket, but if there is still an issue here, please open a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 14:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 14:53:52 -0000 Subject: [GHC] #12931: tc_infer_args does not set in-scope set correctly In-Reply-To: <046.c5bac8525d250f0afb084b2b372797bb@haskell.org> References: <046.c5bac8525d250f0afb084b2b372797bb@haskell.org> Message-ID: <061.241bd40ac9c480e61ba7800cfa188991@haskell.org> #12931: tc_infer_args does not set in-scope set correctly -------------------------------------+------------------------------------- Reporter: johnleo | 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12549 #11371 | Differential Rev(s): #12785 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: This has been fixed with the recent refactoring of `tc_infer_args` (791947db6db32ef7d4772a821a0823e558e3c05b). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 15:52:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 15:52:43 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.e809b198dbf4da0a77dc1c49bb5ad4c2@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): > The perf results don't look very promising for this branch. Perhaps, but I'm not sure whether this is really all due to `prettyprinter`. Afterall, we also now build `text` as well. Really the branch needs to be rebased before we can really say much about its compilation time impact. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 16:22:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 16:22:38 -0000 Subject: [GHC] #13617: GHCi linker does not honor alignment of sections. In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.420baf84906a6a95e354a441f0d33142@haskell.org> #13617: GHCi linker does not honor alignment of sections. --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 16:28:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 16:28:03 -0000 Subject: [GHC] #14117: stg-lint fails on unlifted-type join point binding Message-ID: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> #14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 validating GHC with `BuildFlavour=devel2` and `-dstg-lint` I found that the linter chokes when it finds a join point of unlifted type (like this one from the `Binary` module), {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [RHS of $j_sDSL :: (# State# RealWorld, () #)] Let(rec) binder ‘$j_sDSL’ has unlifted type ‘(# State# RealWorld, () #)’ RHS: \r [] src src src src case readIntArray# [ww_sDSF 0# w1_sDSJ] of { ... }}} If I'm not mistaken there is no problem with join points having unlifted type (see `Note [CoreSyn let/app invariant]`). We just need to update the STG linter appropriately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 16:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 16:36:16 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.6c5e495c12d5940573ae22da227413a0@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): That seems to be indeed the case. I cherry picked this commit (together with some related ones, as detailed in [ticket:13719#comment:8]) into the `8.2` branch. This got rid of the issue reported here, but the original issue in #13803, `ghc` panicking when building `gi-gio`, is still there... Sigh. Now I am not sure how to proceed. I can try to reduce the panic with the patches above applied to the `8.2` branch, and file yet another issue. Would that be the best way to proceed? Or should I reopen the original #13803? In either case the whole process of reducing and bisecting is extremely time consuming, I would really appreciate some guidance (even if it is just a guess). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 16:55:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 16:55:44 -0000 Subject: [GHC] #13617: GHCi linker does not honor alignment of sections. In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.61ccf13e2b904c937af31be860076cc1@haskell.org> #13617: GHCi linker does not honor alignment of sections. --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): This has been fixed as part of a larger patch {{{ Tamar at Destiny MINGW64 /e/temp/hmatrix-segfault $ echo main | ~/ghc/inplace/bin/ghc-stage2.exe --interactive exe/Main.hs GHCi, version 8.3.20170812: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( exe\Main.hs, interpreted ) Ok, 1 module loaded. *Main> [1,1,1,1,1,1,1,1,1,1,1,1] *Main> Leaving GHCi. }}} It will be posted in 1-2 weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 17:16:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 17:16:28 -0000 Subject: [GHC] #14118: stg2stg passes appear to produce invalid STG Message-ID: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> #14118: stg2stg passes appear to produce invalid STG -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 building with GHC with `-dstg-lint -g3 -O0` (after fixing #14116 and #14117) I encountered a rather peculiar error, {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id integer-gmp-1.0.1.0 -hide-all-packages -i -ilibraries/integer-gmp/src/ -ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/include -optP-include -optPlibrari es/integer-gmp/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.1.0 -this-unit-id integer-gmp -Wall -XHaskell2010 -O -dcore- lint -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lin t -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical- monad-instances -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/intege r-gmp/dist-install/build -dynamic-too -c libraries/integer- gmp/src//GHC/Integer/Type.hs -o libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o -dyno libraries/integer-gmp/dist- install/build/GHC/Integer /Type.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders m0_scBy :: State# s_a2Em -> State# s_a2Em, s1_scBz :: State# s_a2Em] s'_scBA is out of scope : warning: [in body of lambda with binders wild1_sdUv :: Int#] qr_sdUp is out of scope }}} Looking at the STG it appears that these warnings are absolutely correct, {{{#!hs svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (State# s -> State# s) -> S s () [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = \r [m0_scBy s1_scBz] src case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src (#,#) [s'_scBA ()]; }; }}} This is quite strange given that `s'_scBA` is clearly in scope, being bound as the case binder. We had the following from Core Prep, {{{#!hs -- RHS size: {terms: 10, types: 17, coercions: 0, joins: 0/0} GHC.Integer.Type.svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (GHC.Prim.State# s -> GHC.Prim.State# s) -> GHC.Integer.Type.S s () [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] GHC.Integer.Type.svoid = \ (@ s_a2Em) (m0_scBy [Occ=Once!] :: GHC.Prim.State# s_a2Em -> GHC.Prim.State# s_a2Em) (s1_scBz [Occ=Once] :: GHC.Prim.State# s_a2Em) -> src case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src (# s'_scBA, GHC.Tuple.() #) } }}} The reason the linter fails here is due to the following logic in `lintStgExpr`, {{{#!hs in_scope <- MaybeT $ liftM Just $ case alts_type of AlgAlt tc -> check_bndr (tyConPrimRep tc) >> return True PrimAlt rep -> check_bndr [rep] >> return True MultiValAlt _ -> return False -- Binder is always dead in this case PolyAlt -> return True MaybeT $ addInScopeVars [bndr | in_scope] $ lintStgAlts alts scrut_ty }}} In the `svoid` case above we hit `MultiValAlt` path, which causes us to ignore the case binder. The fact that we hit `MultiValAlt` at all is a bit surprising given that the result is not an unboxed sum or tuple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 17:16:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 17:16:58 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter (was: stg2stg passes appear to produce invalid STG) In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.0a9b506bdb7ce73d66add9e4484082c8@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 17:21:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 17:21:37 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.4c202bc3000daafa4f5dbe610ee061a6@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The `MultiValAlt` here arises from `CoreToStg.mkStgAltType`, which looks at the `typePrimRep` of the case binder to determine the `AltType`, {{{#!hs = case typePrimRep bndr_ty of [LiftedRep] -> case tyConAppTyCon_maybe (unwrapType bndr_ty) of Just tc | isAbstractTyCon tc -> look_for_better_tycon | isAlgTyCon tc -> AlgAlt tc | otherwise -> ASSERT2( _is_poly_alt_tycon tc, ppr tc ) PolyAlt Nothing -> PolyAlt [unlifted] -> PrimAlt unlifted not_unary -> MultiValAlt (length not_unary) }}} Here we are hitting the `not_unary` case where `length not_unary == 0` since the binder is of type `State# s`, which is void. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:44:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:44:16 -0000 Subject: [GHC] #14119: Refactor type patterns Message-ID: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 12564, 14038 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type patterns are used in instance heads: class instances, type instances, and data/newtype instances. These type patterns differ from ordinary types in several ways: * They must never mention a `forall`. * They must never mention a context. (The context in a class instance head is a different part of the instance construct.) * They must never mention a type family. Types that appear as arguments on the LHS of a RULE should also be type patterns. Type patterns are used in GHC differently than types as well: we should match only against patterns, never ordinary types. I thus propose that a new datatype within GHC to store type patterns. I'll call it `TyPat` here, but perhaps a longer name is better. The matcher (in the `Unify` module) would then take a `TyPat` parameter, making clear which type is the template and which is the concrete instantiation. We could have a new algorithm to typecheck/desugar source syntax into patterns. This new algorithm could accommodate issues like those mentioned in comment:6:ticket:14038. It could also avoid ever putting a type family in a kind parameter, which would fix #12564. Separating out checking type patterns from proper types could also improve GADT pattern matching in types, which is currently more like "wobbly types" than OutsideIn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:45:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:45:00 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.1bcdd0b2f7a5c673e5ade6bf2aa33cae@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): An important question here is: should we do this at all? If I have my way and Dependent Haskell comes along, then types and terms will be the same. And we already have term patterns! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:45:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:45:46 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.265badc91906435c633362f7a50af785@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've made a new ticket to discuss how to deal with type patterns at #14119, which this ticket is blocked by. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:46:13 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.15fa91af7e694db09e2e223e1ce203a1@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've made a new ticket #14119 discussing a refactoring of type patterns. That ticket would solve this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:51:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:51:00 -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.415e1db043474f6268da0f7bf0b54c7b@haskell.org> #12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): This is fixed now. Will add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:53:15 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.796848221338711d6e64bad14a6ee485@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: Silly question: are you proposing that we introduce a counterpart for `HsType` (from user syntax) for type patterns? A counterpart to `Type` (from Core) for type patterns? Both? If a counterpart for `HsType` is in the works, I think it would be a good idea for another reason. Currently, there are some niceties that term- level patterns provide which aren't available for type-level patterns, such as as-patterns (e.g., `x@(Just y)`). If we had a separate data type(s) for type patterns, it would be much easier to add support for this feature, since we would have a way to rule out the use of as-patterns in non-pattern types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:55:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:55:37 -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.5ae88d100fa8967c7aca746587518f4b@haskell.org> #12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This is fixed now. Adding a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:58:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:58:27 -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.73ff37934df56499664bafa3710bb4d4@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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a dup of #13364. But this one has more commentary, so keeping this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:58:56 -0000 Subject: [GHC] #13364: Remove checkValidTelescope In-Reply-To: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> References: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> Message-ID: <062.e25a8913dab7a410f8e27ef9a1d38583@haskell.org> #13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | 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 goldfire): * status: new => closed * resolution: => duplicate Comment: This is a dup of #14066. Closing, as that one has better commentary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 18:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 18:59:35 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.b8d683fa9de080f77a255215c0155f55@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 20:35:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 20:35:05 -0000 Subject: [GHC] #14116: STG lint error while compiling master In-Reply-To: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> References: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> Message-ID: <061.6221f53f2ce0fe1f81c69825510a740d@haskell.org> #14116: STG lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.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:D3856 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3856 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 20:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 20:42:47 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.20bf79e03292fbcc3f229506be789054@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3858 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:04:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:04:26 -0000 Subject: [GHC] #14120: stg-lint is hopelessly broken Message-ID: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> #14120: stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch any type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:04:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:04:37 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken (was: stg-lint is hopelessly broken) In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.fcad9b127c7b0840c40fc4727aa7a8c1@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:18:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:18:34 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.f44a87cdfc8040a80984c786bf17b868@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I was thinking only of a counterpart to `Type`, not `HsType`. Your comment about type-level as-patterns is a good observation. It may be worth considering the situation in terms: Currently both patterns and expressions are parsed as expressions. (I believe there is some scenario where the parser can't be sure what it's looking at until it's too late. Maybe top-level TH splices. Maybe something more fundamental. The details aren't important here.) Then, another pass converts the expressions to patterns, erroring if the parsed expression doesn't form a pattern. Then, expressions and patterns are renamed and typechecked in different algorithms (mutually recursive ones, of course). Why have `HsPat` distinct from `HsExpr`? One reason I can think of is that `HsPat` is renamed very differently than `HsExpr` is: the former brings variables into scope, while the latter uses variables already in scope. The situation is a bit different in types. In particular, variable usages in type patterns do ''not'' bring those variables into scope. Instead, GHC looks through a type pattern before renaming it, gathers its free variables, and brings them into scope. This is subtly different than just having the variable occurrences bring them into scope, but it allows non- linear patterns, for example. I don't yet see a compelling reason for `HsTyPat`. If you want as- patterns, then we add a new constructor to `HsType`. As-patterns are rejected from the normal type kind-checker but accepted in the type pattern kind-checker. On the other hand, maybe it would indeed be better to have `HsTyPat` distinct from `HsType`.... usually, more types are better, no? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:20:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:20:56 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.b39a24a2ec0cce0e8824fde9811e6bb9@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:9 goldfire]: > .. result kind `u` is actually a ''parameter'' to `F`. This clarified a lot. Thanks for the feedback, it works for me now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:26:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:26:43 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.36d3eaa48d7e017a920612ba9143a520@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): Phab:D3859 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D3859 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:36:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:36:14 -0000 Subject: [GHC] #14117: stg-lint fails on unlifted-type join point binding In-Reply-To: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> References: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> Message-ID: <061.ee09c632d3155493073fc37dcf546497@haskell.org> #14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3857 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3857 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:42:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:42:10 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.1b8764318a8fe5dbadf33721d3e94ae6@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Today I spent a fair amount of time looking at the STG linter, having > encountered a number of times in the past six months where I noticed it > broke. > > While I thought fixing it would just be a few small tweaks, it seems that > with every issue I fix another bug rears its ugly head. So far I have > encountered and fixed, > * #14116 > * #14117 > * #14118 > The solutions to each of these has seemed rather obvious. However, now I > seem to have run into a bit of a more fundamental issue: > > Consider this excerpt extracted from `Foreign.Storable`, > {{{#!hs > {-# LANGUAGE BangPatterns #-} > > module Hi where > > import GHC.Word > import GHC.Ptr > import GHC.Base > import GHC.Num > import Data.Bits > import GHC.Fingerprint.Type > > peekFingerprint :: Ptr Fingerprint -> IO Fingerprint > peekFingerprint p0 = do > let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 > peekW64 _ 0 !i = return i > peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) > > high <- peekW64 (castPtr p0) 8 0 > low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 > return (Fingerprint high low) > }}} > > In particular notice the `castPtr` application. This triggers the STG > linter with, > {{{ > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.3.20170815 for x86_64-unknown-linux): > *** Stg Lint ErrMsgs: in Stg2Stg *** > : warning: > [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, > eta_s2zC :: State# RealWorld] > In a function application, function type doesn't match arg types: > Function type: > Ptr Word8 > -> Int# > -> Word# > -> State# RealWorld > -> (# State# RealWorld, Word64 #) > Arg types: > Ptr Fingerprint > Int# > Word# > State# RealWorld > Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC > }}} > > This is because by the time we are in Core Prep the `castPtr` is turned > into a cast, which we discard in STG. Consequently, it seems that the > comment attached to `stgEqType`, > {{{#!hs > stgEqType :: Type -> Type -> Bool > -- Compare types, but crudely because we have discarded > -- both casts and type applications, so types might look > -- different but be the same. So reply "True" if in doubt. > -- "False" means that the types are definitely different. > -- > -- Fundamentally this is a losing battle because of unsafeCoerce > }}} > is quite an understatement. Rather, there are exceedingly few cases where > we can catch any type errors in STG. I think the only case which we can > reliably catch is that of two types with explicitly different primreps. > It's not clear what we can/should do about this. New description: Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:45:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:45:22 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.4a1eab56e2ae95f2546f928b9b1f2b63@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Today I spent a fair amount of time looking at the STG linter, having > encountered a number of times in the past six months where I noticed it > broke. > > While I thought fixing it would just be a few small tweaks, it seems that > with every issue I fix another bug rears its ugly head. So far I have > encountered and fixed, > * #14116 > * #14117 > * #14118 > The solutions to each of these has seemed rather obvious. However, now I > seem to have run into a bit of a more fundamental issue: > > Consider this excerpt extracted from `Foreign.Storable`, > {{{#!hs > {-# LANGUAGE BangPatterns #-} > > module Hi where > > import GHC.Word > import GHC.Ptr > import GHC.Base > import GHC.Num > import Data.Bits > import GHC.Fingerprint.Type > > peekFingerprint :: Ptr Fingerprint -> IO Fingerprint > peekFingerprint p0 = do > let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 > peekW64 _ 0 !i = return i > peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) > > high <- peekW64 (castPtr p0) 8 0 > low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 > return (Fingerprint high low) > }}} > > In particular notice the `castPtr` application. This triggers the STG > linter with, > {{{ > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.3.20170815 for x86_64-unknown-linux): > *** Stg Lint ErrMsgs: in Stg2Stg *** > : warning: > [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, > eta_s2zC :: State# RealWorld] > In a function application, function type doesn't match arg types: > Function type: > Ptr Word8 > -> Int# > -> Word# > -> State# RealWorld > -> (# State# RealWorld, Word64 #) > Arg types: > Ptr Fingerprint > Int# > Word# > State# RealWorld > Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC > }}} > > This is because by the time we are in Core Prep the `castPtr` is turned > into a cast, which we discard in STG. Consequently, it seems that the > comment attached to `stgEqType`, > {{{#!hs > stgEqType :: Type -> Type -> Bool > -- Compare types, but crudely because we have discarded > -- both casts and type applications, so types might look > -- different but be the same. So reply "True" if in doubt. > -- "False" means that the types are definitely different. > -- > -- Fundamentally this is a losing battle because of unsafeCoerce > }}} > is quite an understatement. Rather, there are exceedingly few cases where > we can catch type errors in STG. I think the only case which we can > reliably catch is that of two types with explicitly different primreps. > It's not clear what we can/should do about this. New description: Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I needed to use it but noticed it was broken. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 21:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 21:49:28 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.c4838fc821b9329ce93a12a9a3d9d77f@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): Phab:D3860 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D3860 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 22:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 22:25:42 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not Message-ID: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was found while building https://hackage.haskell.org/package/foundation with ghc head. The following code is reduced from Basement.Primitive.Error: {{{ {-# LANGUAGE MagicHash, PolyKinds, RankNTypes #-} module FoundationRegression where import GHC.Prim import GHC.Types (RuntimeRep) error :: forall (r :: RuntimeRep) . forall (a :: TYPE r) . String -> a error s = raise# undefined }}} This compiles works with 8.2.1, but fails on master: {{{ $ /opt/ghc/8.2.1/bin/ghc -c FoundationRegression.hs $ /opt/ghc/head/bin/ghc -c FoundationRegression.hs FoundationRegression.hs:7:17: error: Variable ‘r’ used as both a kind and a type Did you intend to use TypeInType? | 7 | error :: forall (r :: RuntimeRep) . forall (a :: TYPE r) . String -> a | ^^^^^^^^^^^^^^^^^ }}} After adding a TypeInType language pragma the program is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 22:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 22:59:00 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.35944134f82b9359385183da5a8e2418@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I hit a similar issue recently in the land of 8.2.1, and I was surprised that datakinds didn't suffice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 22:59:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 22:59:22 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.d9202164f68c58b6cb77a6d56a2df244@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | 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 goldfire): * status: new => closed * resolution: => wontfix Comment: Actually, this is all bogus. In `type G = F`, `F` is undersaturated, which is disallowed. And once we write `type G z = F z`, when we're inferring a higher-rank type for `z`, we've gone further off the map than I'm comfortable with. Additionally, getting this right would require tracking recursiveness in type declarations more than we do already, and it's not worth the pain. So I'm closing as wontfix. Anyone who wants this can always add a kind signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:30:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:30:52 -0000 Subject: [GHC] #14122: Core lint error while compiling GHC.IO.Handle Message-ID: <046.2391c0290c34ee83dfcea71f37a050f4@haskell.org> #14122: Core lint error while compiling GHC.IO.Handle -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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 compiling `GHC.IO.Handle` with `-g3 -dcore-lint -O` I encountered the following, {{{ *** Core Lint errors : in result of Simplifier *** : warning: [RHS of w1_s8qY :: Addr#] Recursive or top-level binder has strict demand info: w1_s8qY Binder's demand info: }}} The binding in question is, {{{#!hs w1_s8qY :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] w1_s8qY = src src "}"# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:39:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:39:15 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.1d326ba2571228f472b732940caf5e63@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8472 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #8472 Old description: > The Core string literals patch > [[https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3|regresses]] > compiler performance by nearly 5%. > > We should really understand why this is; this is a huge regression for > something that really shouldn't be costly. New description: The Core string literals patch [[https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3|regresses]] (see #8472) compiler performance by nearly 5%. We should really understand why this is; this is a huge regression for something that really shouldn't be costly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:44:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:44:27 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.f28b6a9c24ea3b633676e34d7dfc4fb7@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:47:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:47:12 -0000 Subject: [GHC] #10809: Add prefetch{Small}{Mutable}Array[0..3]# In-Reply-To: <045.362862b9c795f03f22e13a10bddfcc8c@haskell.org> References: <045.362862b9c795f03f22e13a10bddfcc8c@haskell.org> Message-ID: <060.f9cd68de51d39c306f3202feb328300d@haskell.org> #10809: Add prefetch{Small}{Mutable}Array[0..3]# -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: prefetch 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 bgamari): * keywords: => prefetch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:48:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:48:26 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.efcd0f513b83765c9bcdd4599e093ad6@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #5877 #10064 #11312 => #5877 #10064 #11312, #9719 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:49:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:49:29 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.c8591abeef6c695656464708ceaa94c4@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomers Comment: If anyone is interested in picking this up do ping me. It should be a relatively straightforward patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:52:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:52:14 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.f70ede3f3f0b4d35ebd39bc21d7d71e1@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | 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): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * differential: D3839 => Phab:D3839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:52:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:52:39 -0000 Subject: [GHC] #12155: Description of flags cut off In-Reply-To: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> References: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> Message-ID: <060.b44494cfe24e3f9c9d3f4253ea17e674@haskell.org> #12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: (none) Type: task | Status: patch Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: flags Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #11654 | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * differential: D3839 => Phab:D3839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:53:42 -0000 Subject: [GHC] #13390: String literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.79b26243cfc5983b4c3855e60d15e14c@haskell.org> #13390: String literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: strings 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: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:53:55 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.33db219b92c00a4b5f45e10460b55b77@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8472 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:54:17 -0000 Subject: [GHC] #13317: exprIsConApp_maybe should deal better with strings In-Reply-To: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> References: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> Message-ID: <061.dab62361d1c4cd7f1fd0d86d3d6571b4@haskell.org> #13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13317 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:54:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:54:30 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.27e0915de838b6db3cb35a860ae57e72@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: newcomer, | strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T13260 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3286 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: newcomer => newcomer, strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:54:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:54:41 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.d425ce75792e7e6f6bafc1541f932056@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: strings 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): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:55:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:55:00 -0000 Subject: [GHC] #13367: CSE not working for top-level literal strings In-Reply-To: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> References: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> Message-ID: <061.4545a1318dd1866523c06b9ccb3d19cf@haskell.org> #13367: CSE not working for top-level literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13367 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings Old description: > Consider > {{{ > {-# LANGUAGE MagicHash #-} > module S( z ) where > import GHC.Exts > > data T = MkT Addr# > > x = MkT "foo"# > y = MkT "foo"# > > z = (x,y) > }}} > You'd expect those literal strings to get CSE'd but currently they are > not. New description: Consider {{{#!hs {-# LANGUAGE MagicHash #-} module S( z ) where import GHC.Exts data T = MkT Addr# x = MkT "foo"# y = MkT "foo"# z = (x,y) }}} You'd expect those literal strings to get CSE'd but currently they are not. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:56:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:56:04 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.b0e00ee4fcf14c9fa7b557003bd0b0c3@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:56:20 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.09938dfd7dafd77baf5121b25d5007f4@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292, #5218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:57:00 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.1ec61838f24c4ba63f19306a42d2a05a@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: newcomer, | strings Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: newcomer => newcomer, strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:59:01 -0000 Subject: [GHC] #10922: String inlining is inconsistent In-Reply-To: <045.1248535f4fce805677912aba5d04066f@haskell.org> References: <045.1248535f4fce805677912aba5d04066f@haskell.org> Message-ID: <060.81652c2b5176968d519ba46ed53db9da@haskell.org> #10922: String inlining is inconsistent -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 15 23:59:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Aug 2017 23:59:58 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.83b4d4a5a4b811a4bc35947f15dcc1e5@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:00:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:00:50 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.ab946935796200f10ab9287e5e430162@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: strings 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 bgamari): * keywords: => strings Old description: > A string constant in GHC turns into > {{{ > foo :: String > foo = unpackCString# "the-string' > }}} > This is a top-level thunk, and it expands into rather a lot of code like > this > {{{ > .text > .align 4,0x90 > .long 0 > .long 22 > .globl _Foo_zdfTypeableTzuds1_info > _Foo_zdfTypeableTzuds1_info: > .LcvI: > movl %esi,%eax > leal -12(%ebp),%ecx > cmpl 84(%ebx),%ecx > jb .LcvQ > addl $8,%edi > cmpl 92(%ebx),%edi > ja .LcvS > movl $_stg_CAF_BLACKHOLE_info,-4(%edi) > movl 100(%ebx),%ecx > movl %ecx,0(%edi) > leal -4(%edi),%ecx > pushl %ecx > pushl %eax > pushl %ebx > movl %eax,76(%esp) > call _newCAF > addl $12,%esp > testl %eax,%eax > je .LcvL > movl $_stg_bh_upd_frame_info,-8(%ebp) > leal -4(%edi),%eax > movl %eax,-4(%ebp) > movl $_cvJ_str,-12(%ebp) > addl $-12,%ebp > jmp _ghczmprim_GHCziCString_unpackCStringzh_info > .LcvL: > movl 64(%esp),%eax > jmp *(%eax) > .LcvS: > movl $8,116(%ebx) > .LcvQ: > movl %eax,%esi > jmp *-12(%ebx) > }}} > That's rather a lot of goop for one thunk! Of course we can share this, > by making a 2-word thunk like this: > {{{ > ------------------------------ > | TopUnpack_info | -------|-----> "the-string"# > ------------------------------ > }}} > where `TopUnpack_info` is a shared RTS info-table and code that embodies > the code fragment above. > > This would save useless code bloat for every constant string. (This came > up when looking at the code generated by `deriving(Typeable)`.) New description: A string constant in GHC turns into {{{#!hs foo :: String foo = unpackCString# "the-string' }}} This is a top-level thunk, and it expands into rather a lot of code like this {{{ .text .align 4,0x90 .long 0 .long 22 .globl _Foo_zdfTypeableTzuds1_info _Foo_zdfTypeableTzuds1_info: .LcvI: movl %esi,%eax leal -12(%ebp),%ecx cmpl 84(%ebx),%ecx jb .LcvQ addl $8,%edi cmpl 92(%ebx),%edi ja .LcvS movl $_stg_CAF_BLACKHOLE_info,-4(%edi) movl 100(%ebx),%ecx movl %ecx,0(%edi) leal -4(%edi),%ecx pushl %ecx pushl %eax pushl %ebx movl %eax,76(%esp) call _newCAF addl $12,%esp testl %eax,%eax je .LcvL movl $_stg_bh_upd_frame_info,-8(%ebp) leal -4(%edi),%eax movl %eax,-4(%ebp) movl $_cvJ_str,-12(%ebp) addl $-12,%ebp jmp _ghczmprim_GHCziCString_unpackCStringzh_info .LcvL: movl 64(%esp),%eax jmp *(%eax) .LcvS: movl $8,116(%ebx) .LcvQ: movl %eax,%esi jmp *-12(%ebx) }}} That's rather a lot of goop for one thunk! Of course we can share this, by making a 2-word thunk like this: {{{ ------------------------------ | TopUnpack_info | -------|-----> "the-string"# ------------------------------ }}} where `TopUnpack_info` is a shared RTS info-table and code that embodies the code fragment above. This would save useless code bloat for every constant string. (This came up when looking at the code generated by `deriving(Typeable)`.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:01:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:01:21 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.cb552fe328e9cd252f72a6a549ddcc02@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => strings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:02:09 -0000 Subject: [GHC] #2840: Top level string literals In-Reply-To: <046.8553bc6421fed56d88dda5bac312c55f@haskell.org> References: <046.8553bc6421fed56d88dda5bac312c55f@haskell.org> Message-ID: <061.a50ef50dfd253f5d58f02c490749ff36@haskell.org> #2840: Top level string literals -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: strings 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 bgamari): * keywords: => strings Old description: > At the moment GHC's internal language does not allow any top-level > definitions of unlifted type, and for the most part rightly so. But > consider this: > {{{ > f :: Int -> String > f n = let a::Addr# = "foo" > in let g y = ...a...g... > in g n > }}} > Here we'd like to float the definitions out thus: > {{{ > a::Addr# = "foo" > g y = ...a...g... > f n = g n > }}} > This is much better. Usually this happens, but not here, because we > don't allow a top-level binding for an `Addr#`. But really perhaps we > should allow an exception for ''literals'', which can safely be bound at > top level. > > For literals other than strings, this doesn't make any difference, > because we inline them freely. But for literal strings we don't want to > make lots of copies of them; on the contrary we'd like to CSE identical > strings. So it'd help to be able to bind them at top level. > > Simon New description: At the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this: {{{#!hs f :: Int -> String f n = let a::Addr# = "foo" in let g y = ...a...g... in g n }}} Here we'd like to float the definitions out thus: {{{#!hs a::Addr# = "foo" g y = ...a...g... f n = g n }}} This is much better. Usually this happens, but not here, because we don't allow a top-level binding for an `Addr#`. But really perhaps we should allow an exception for ''literals'', which can safely be bound at top level. For literals other than strings, this doesn't make any difference, because we inline them freely. But for literal strings we don't want to make lots of copies of them; on the contrary we'd like to CSE identical strings. So it'd help to be able to bind them at top level. Simon -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:03:29 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.d44d0829fdeddef52bacdf8e696e0c70@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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 bgamari): Iavor, what is the status of your plugin? Given that it seems unlikely that we'll merge an SMT solver into GHC, perhaps we should close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:16:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:16:08 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core Message-ID: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC, * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a `typePrimRep` panic. * ticket:8472#comment:22: a tick wraps a primitive string literal, causing `CoreToStg` to fail to notice it is a string resulting in a panic * #14122: Another literal string issue which I have yet to debug but seems very likely to be tick-related. We have merged a stop-gap solution/hack (f5b275a239d2554c4da0b7621211642bf3b10650) to the `ghc-8.2` branch however need a more principled solution in the long-term (e.g. before 8.4). We will need to start by defining precisely where ticks are allowed and add appropriate logic to CoreLint to verify that this invariant is upheld. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:19:05 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.a21032149738d038229dc0601c2f76e1@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj, JaffaCake (added) Old description: > In the past we have had a number of issues stemming from ticks breaking > various Core analyses in GHC, > > * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed > tuple tycon) from its levity arguments, resulting in a `typePrimRep` > panic. > * ticket:8472#comment:22: a tick wraps a primitive string literal, > causing `CoreToStg` to fail to notice it is a string resulting in a panic > * #14122: Another literal string issue which I have yet to debug but > seems very likely to be tick-related. > > We have merged a stop-gap solution/hack > (f5b275a239d2554c4da0b7621211642bf3b10650) to the `ghc-8.2` branch > however need a more principled solution in the long-term (e.g. before > 8.4). We will need to start by defining precisely where ticks are allowed > and add appropriate logic to CoreLint to verify that this invariant is > upheld. New description: In the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC, * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a `typePrimRep` panic. * ticket:8472#comment:22: a tick wraps a primitive string literal, causing `CoreToStg` to fail to notice it is a string resulting in a panic * #14122: Another literal string issue which I have yet to debug but seems very likely to be tick-related. We have merged a stop-gap solution/hack (f5b275a239d2554c4da0b7621211642bf3b10650) to the `master` branch (present in GHC 8.2.1) however we will need a more principled solution in the long- term (e.g. before 8.4). We will need to start by defining precisely where ticks are allowed and add appropriate logic to `CoreLint` to verify that this invariant is upheld. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:20:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:20:25 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.f703a3986bbca8cc0cd2c7be0844a743@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: newcomer, | strings Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by bgamari): The patch described in comment:22 is in the `master` branch and GHC 8.2.1 and is a temporary workaround for some of the breakage caused by this change. The general theme of breakage-due-to-ticks is tracked in #14123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:20:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:20:52 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.68d95b3d1b4eaf9028c2637bea098360@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: #14123 | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14123 Comment: I have opened #14123 to track the general theme of breakage-due-to-ticks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:21:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:21:44 -0000 Subject: [GHC] #14122: Core lint error while compiling GHC.IO.Handle In-Reply-To: <046.2391c0290c34ee83dfcea71f37a050f4@haskell.org> References: <046.2391c0290c34ee83dfcea71f37a050f4@haskell.org> Message-ID: <061.4145011bde4240661eca12498c67e9bf@haskell.org> #14122: Core lint error while compiling GHC.IO.Handle -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: #14123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14123 Comment: This is yet another manifestation of ticks obscuring the string-y nature of the binding. See #8472, #13233, and #14123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:22:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:22:45 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.8a3a7ff29168ac2762b99a656e9d848b@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: This program should indeed require `TypeInType`, and the fact that it is accepted without `TypeInType` in 8.2.1 is a fluke. The ability to bind a kind variable and use it as the kind of a different type variable in the same telescope is something that wasn't possible in a pre-`TypeInType` GHC, as this error message in GHC 7.10.3 reveals: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help λ> :set -XKindSignatures -XRankNTypes -XPolyKinds λ> import Data.Proxy λ> let f :: forall (k :: *). forall (a :: k). Proxy a; f = Proxy :4:10: Kind variable also used as type variable: ‘k’ In the type signature for ‘f’ }}} `RuntimeRep` wasn't introduced until 8.0, so I can't test your exact example in 7.10.3. But the principle is the same: if you use something as both type and kind, then you need `TypeInType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:31:10 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.af9034e2f51275c52f93998717e85dd3@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phab:D3051 is the current approach which we have in the tree. Phab:D3063 is one potential alternative which requires a bit of honing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 00:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 00:36:31 -0000 Subject: [GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports In-Reply-To: <042.badab7c0b70bc218549980e1ff162223@haskell.org> References: <042.badab7c0b70bc218549980e1ff162223@haskell.org> Message-ID: <057.e5f207d35e9c0ed694997a8bbe101ff9@haskell.org> #9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9281, #11032 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The behavior observed by hvr in comment:7 is (was?) in fact intentional. It is documented in this note in `TyType`, {{{ Note [Marshalling void] ~~~~~~~~~~~~~~~~~~~~~~~ We don't treat State# (whose PrimRep is VoidRep) as marshalable. In turn that means you can't write foreign import foo :: Int -> State# RealWorld Reason: the back end falls over with panic "primRepHint:VoidRep"; and there is no compelling reason to permit it }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 02:22:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 02:22:04 -0000 Subject: [GHC] #14124: add shrink prim-op for other array type Message-ID: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> #14124: add shrink prim-op for other array type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This issue arised in the recently PR to bring unified array interface to primitive: https://github.com/haskell/primitive/pull/64 . In that issue andrewthad ask if we want to keep `shrikArr` API. My guts feels that it's possible for other type of array as well since it's just the same closure overwrite thing. So i'm asking for adding such prim-op here. I suppose we should provide `getSizeOfXXX` prim-op which consume a state token for other array type as well since the array size is not referential transparent now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 02:23:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 02:23:20 -0000 Subject: [GHC] #14124: add shrink prim-op for other array type In-Reply-To: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> References: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> Message-ID: <060.fbb1dd0ae05dcc6d5e3ab06c868b755b@haskell.org> #14124: add shrink prim-op for other array type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by winter: Old description: > This issue arised in the recently PR to bring unified array interface to > primitive: https://github.com/haskell/primitive/pull/64 . In that issue > andrewthad ask if we want to keep `shrikArr` API. My guts feels that it's > possible for other type of array as well since it's just the same closure > overwrite thing. So i'm asking for adding such prim-op here. > > I suppose we should provide `getSizeOfXXX` prim-op which consume a state > token for other array type as well since the array size is not > referential transparent now. New description: This issue arised in the recently PR to bring unified array interface to primitive: https://github.com/haskell/primitive/pull/64 . In that PR andrewthad ask if we want to keep `shrinkArr` API. My guts feeling says it's possible for other type of array as well since it's just the same closure overwrite thing. So i'm asking for adding such prim-op here. I suppose we should provide `getSizeOfXXX` prim-op which consume a state token for other array type as well since the array size is not referential transparent now. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 02:51:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 02:51:00 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.c4946bd2c34c9a9999574e6380e62b5c@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I don't think it's a good idea to change the string literal desguaring: there're too many libraries rely on the old `Addr#` desugaring behaviour, changing it will break them. And null terminate modified UTF-8 strings are useful: for example a filepath literal. It's also more compact, which is why we choose it in the first place. So no matter what, i will ask that new desugaring literals should be added together with a new syntax, e.g. the primitive version has already differ in syntax: `##` vs `#`. I would propose adding a new syntax `""...""`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 03:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 03:01:31 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.cac276abb7c48bb3199f580b26f01e9f@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Thanks for the great explanation! Should this be in the release notes, or is it too niche? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 03:28:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 03:28:33 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.86459da27eadc87d8c65c42c03d2172c@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 03:33:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 03:33:39 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.1f1443e2620ec29d2ccb85044e4787bf@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): build.mk file used {{{ GhcRTSWays += debug GhcRTSWays += debug_p GhcRTSWays += thr_debug GhcRTSWays += thr_debug_p BUILD_DOCBOOK_HTML = YES DYNAMIC_GHC_PROGRAMS = YES }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 03:35:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 03:35:03 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.db13763b3a18c30ed7ad9f5e4c992c8c@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:74 jscholl]: > Thinking about the problem again I decided to try to add {{{ByteArray#}}} literals to GHC. The idea is the following: > - Use {{{"foo"##}}} as syntax for {{{ByteArray#}}}s. This is in essence my try for a {{{String#}}} type. > - Provide > {{{#!haskell > unpackStringLit# :: ByteArray# -> [Char] > {-# INLINE[1] unpackStringLit# #-} > unpackStringLit# ba# = > unpackCStringWithLen# (byteArrayContents# ba#) (sizeofByteArray# ba#) > }}} > - Compile {{{"foo"}}} as {{{unpackStringLit# "foo"##}}} > - Let rewrites fire in phase 2. > - In phase 1, inline {{{unpackStringLit#}}} and let rules rewrite it to {{{unpackCStringWithLen# "foo"# 3#}}} > - Thus most {{{ByteArray#}}}s should get eliminated and binary size should stay more or less the same. > - If someone rewrites something like {{{ByteString.pack (unpackStringLit# lit)}}}, the literal is not eliminated and emitted to the binary. Thus a {{{ByteString}}} literal can increase binary size. However, I think this is what we want because we save making a copy of the data. > - The downside is that turning optimization off causes the compiler to create a {{{ByteArray#}}} for every string literal instead of a c-string. GHCi will also allocate {{{ByteArray#}}}s instead of string literals directly. > The problem is, old `Addr#` unpacking differ from `ByteArray#` unpacking in that they are not the same encoding: they don't agree on how `\NUL` char get encoded, (at least I'm expecting `ByteArray#` is standard UTF-8 encoded). So you can't cast them with rewrite rules like that: you have to mention the encoding pitfall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 03:40:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 03:40:37 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.cc7d8b8c3f9451c20ddafb5b4c99b068@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): There's no segfaults when this commit 834e350bd9b54bf465f2fef880e18f412fea57d3 + this patch {{{ diff --git a/rts/linker/Elf.c b/rts/linker/Elf.c index df3560476c..efa10fd883 100644 --- a/rts/linker/Elf.c +++ b/rts/linker/Elf.c @@ -98,6 +98,13 @@ # define R_X86_64_PC64 24 # endif +# ifndef R_X86_64_GOTPCRELX +# define R_X86_64_GOTPCRELX 41 +# endif +# ifndef R_X86_64_REX_GOTPCRELX +# define R_X86_64_REX_GOTPCRELX 42 +# endif + /* * Workaround for libc implementations (e.g. eglibc) with incomplete * relocation lists @@ -1471,6 +1478,8 @@ do_Elf_Rela_relocations ( ObjectCode* oc, char* ehdrC, # endif #if x86_64_HOST_ARCH + case R_X86_64_NONE: + break; case R_X86_64_64: *(Elf64_Xword *)P = value; break; }}} are compiled using this build.mk {{{ BuildFlavour = perf GhcRTSWays += debug GhcRTSWays += debug_p GhcRTSWays += thr_debug GhcRTSWays += thr_debug_p BUILD_DOCBOOK_HTML = YES ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif STRIP_CMD = : DYNAMIC_GHC_PROGRAMS = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 05:02:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 05:02:40 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.38388edc3bc0dc3acff2ea4abbc7cd14@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): Downloaded source distribution (ghc-8.2.1-src.tar.xz) compiled with either of two build.mk files given in this ticket segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 05:12:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 05:12:56 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.6333d4ddd848921ee17c87df0844c00f@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): After thinking about this for a while, i think a better solution for literal problem is to overhaul the `OverloaddedStrings` extension, because the problem is created by it: without it we can't even use rewrite rules to get the `Addr#` at all. I think i will make a GHC proposal finally, but let me sketch a little bit on my idea: 1. Currently when `OverloaddedStrings` is enabled, we consider a string literal polymorphric by translating them to `fromString ...`, where `fromString` is a method from `IsString` type class. 2. This makes desugaring literal into `String` the first step in during literal compiling, and at this very step we choose to use `unpackCString# addr#` to desugar the literal. 3. Now we have a problem with the fixed desugaring scheme, it's not flexible enough to give arise a `ByteArray#` based representation, no matter what rewrite-rules are applied afterwards. 4. So i proposal to solve the problem directly at this language extension level, besides `IsString`, i propose to add following typeclass: {{{ class IsPlainAddr a where fromPlainAddr :: Addr# -> a class IsAsciiByteArray a where fromAsciiByteArray :: ByteArray# -> a class IsU8ByteArray a where fromU8ByteArray :: ByteArray# -> a -- maybe someone want utf-16 desugaring? we can add later }}} 5. Together with `IsString`, these typeclasses are special when `OverloaddedStrings` is enabled, we will try to find an instance of the type which we are overloading: If we have a `"Foo" :: Foo`, we will try to find a instance for `Foo` among these classes, the priority of those instances can have an arbitrary order as long as we document it clearly. 6. Once an instance is found, we do desugaring depending on the instance spec, and directly inject `fromXXX "xxx"#` into code, if the sourcecode codepoint can't be encoded with the instance spec, we issue a compile waring. 7. If we failed to find an instance from above, we issue an compile error. 8. Now a library author can choose to implement a type class which suit his/her need. 9. This solution can also be extended to handle `OverloadedLists`, e.g. we can add following typeclass for desugaring list literals: {{{ class IsIntList a where fromIntList :: ByteArray# -> a class IsWordList a where fromWordList :: ByteArray# -> a class IsInt8List a where fromInt8List :: ByteArray# -> a ... }}} 10. When `OverloaddedLists` is enabled, we will try to find an instance of these special classes, and transform the list into `ByteArray#` according to the instance spec, if there're overflowing we issue warnings. If later, people ask for new format of literal desugaring, we add new typeclasses and done, old code continue to work, and new code will got a compile error on old compilers. BTW. I think this is what we called "解铃还需系铃人" in chinese ; ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 06:11:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 06:11:09 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. Message-ID: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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'm try to abstract FFI return type so that different errno scheme can work together, namely i create such a class: {{{ class Integral (IOErrno r) => IOReturn r where -- | The errno type associated with 'r' data IOErrno r :: * -- | Is this return value indicate an error? isError :: Integral a => r a -> Bool -- | How can i get a errno then? getErrno :: Integral a => r a -> IO (IOErrno r) -- | Is this errno indicate interrupted blocking call? isInterrupt :: IOErrno r -> Bool -- | Is this errno indicate no data on a non-blocking device? isBlock :: IOErrno r -> Bool -- | OK, i want my return value if no errno. getReturn :: Integral a => r a -> a -- | Read the errno name for me. nameErrno :: IOErrno r -> IO String -- | Read the errno description for me. descErrno :: IOErrno r -> IO String }}} But when i'm try to defining instance for it, such as a standard unix like: {{{ newtype UnixReturn a = UnixReturn a deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) instance IOReturn UnixReturn where newtype IOErrno UnixReturn = UnixErrno CInt deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) isError (UnixReturn r) = r == (-1) isInterrupt e = e == eINTR isBlock e = e == eAGAIN || e == eWOULDBLOCK getErrno _ = get_errno getReturn (UnixReturn r) = r nameErrno = return . nameUnixErrno descErrno e = strerror e >>= peekCString eINTR = UnixErrno (CONST_EINTR) eWOULDBLOCK = UnixErrno (CONST_EWOULDBLOCK) ... foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) }}} I got a error on GHC 8.2: {{{ System/IO/Exception.hs:282:1: error: • Unacceptable argument type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | 282 | foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/IO/Exception.hs:283:1: error: • Unacceptable result type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | 283 | foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} And at every place i want mark my FFI return got this error too. e.g. following code compiles without problem on GHC < 8.2 (Note that the type and constructor are both available): {{{ foreign import CALLCONV unsafe "HsNet.h recv" c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn CSsize) }}} But on GHC 8.2 a `Unacceptable result type in foreign declaration` is emitted. And I think it's a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 06:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 06:11:36 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.8618412d98cc9d428b9d7e303a0133f9@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by winter: Old description: > I'm try to abstract FFI return type so that different errno scheme can > work together, namely i create such a class: > > {{{ > class Integral (IOErrno r) => IOReturn r where > -- | The errno type associated with 'r' > data IOErrno r :: * > -- | Is this return value indicate an error? > isError :: Integral a => r a -> Bool > -- | How can i get a errno then? > getErrno :: Integral a => r a -> IO (IOErrno r) > -- | Is this errno indicate interrupted blocking call? > isInterrupt :: IOErrno r -> Bool > -- | Is this errno indicate no data on a non-blocking device? > isBlock :: IOErrno r -> Bool > -- | OK, i want my return value if no errno. > getReturn :: Integral a => r a -> a > -- | Read the errno name for me. > nameErrno :: IOErrno r -> IO String > -- | Read the errno description for me. > descErrno :: IOErrno r -> IO String > }}} > > But when i'm try to defining instance for it, such as a standard unix > like: > > {{{ > newtype UnixReturn a = UnixReturn a > deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, > FiniteBits, Bits, Storable) > > instance IOReturn UnixReturn where > newtype IOErrno UnixReturn = UnixErrno CInt > deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, > Show, FiniteBits, Bits, Storable) > isError (UnixReturn r) = r == (-1) > isInterrupt e = e == eINTR > isBlock e = e == eAGAIN || e == eWOULDBLOCK > getErrno _ = get_errno > getReturn (UnixReturn r) = r > nameErrno = return . nameUnixErrno > descErrno e = strerror e >>= peekCString > > eINTR = UnixErrno (CONST_EINTR) > eWOULDBLOCK = UnixErrno (CONST_EWOULDBLOCK) > ... > > foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> > IO CString > foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO > (IOErrno UnixReturn) > }}} > > I got a error on GHC 8.2: > > {{{ > System/IO/Exception.hs:282:1: error: > • Unacceptable argument type in foreign declaration: > ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call > • When checking declaration: > foreign import ccall unsafe "string.h" strerror > :: IOErrno UnixReturn -> IO CString > | > 282 | foreign import ccall unsafe "string.h" strerror :: IOErrno > UnixReturn -> IO CString > | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > System/IO/Exception.hs:283:1: error: > • Unacceptable result type in foreign declaration: > ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call > • When checking declaration: > foreign import ccall unsafe "HsBase.h __hscore_get_errno" > get_errno > :: IO (IOErrno UnixReturn) > | > 283 | foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno > :: IO (IOErrno UnixReturn) > | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > And at every place i want mark my FFI return got this error too. e.g. > following code compiles without problem on GHC < 8.2 (Note that the type > and constructor are both available): > > {{{ > > foreign import CALLCONV unsafe "HsNet.h recv" > c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn > CSsize) > }}} > > But on GHC 8.2 a `Unacceptable result type in foreign declaration` is > emitted. And I think it's a regression. New description: I'm trying to abstract FFI return type so that different errno scheme can work together, namely i create such a class: {{{ class Integral (IOErrno r) => IOReturn r where -- | The errno type associated with 'r' data IOErrno r :: * -- | Is this return value indicate an error? isError :: Integral a => r a -> Bool -- | How can i get a errno then? getErrno :: Integral a => r a -> IO (IOErrno r) -- | Is this errno indicate interrupted blocking call? isInterrupt :: IOErrno r -> Bool -- | Is this errno indicate no data on a non-blocking device? isBlock :: IOErrno r -> Bool -- | OK, i want my return value if no errno. getReturn :: Integral a => r a -> a -- | Read the errno name for me. nameErrno :: IOErrno r -> IO String -- | Read the errno description for me. descErrno :: IOErrno r -> IO String }}} But when i'm try to defining instance for it, such as a standard unix like: {{{ newtype UnixReturn a = UnixReturn a deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) instance IOReturn UnixReturn where newtype IOErrno UnixReturn = UnixErrno CInt deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) isError (UnixReturn r) = r == (-1) isInterrupt e = e == eINTR isBlock e = e == eAGAIN || e == eWOULDBLOCK getErrno _ = get_errno getReturn (UnixReturn r) = r nameErrno = return . nameUnixErrno descErrno e = strerror e >>= peekCString eINTR = UnixErrno (CONST_EINTR) eWOULDBLOCK = UnixErrno (CONST_EWOULDBLOCK) ... foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) }}} I got a error on GHC 8.2: {{{ System/IO/Exception.hs:282:1: error: • Unacceptable argument type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | 282 | foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/IO/Exception.hs:283:1: error: • Unacceptable result type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | 283 | foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} And at every place i want mark my FFI return got this error too. e.g. following code compiles without problem on GHC < 8.2 (Note that the type and constructor are both available): {{{ foreign import CALLCONV unsafe "HsNet.h recv" c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn CSsize) }}} But on GHC 8.2 a `Unacceptable result type in foreign declaration` is emitted. And I think it's a regression. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 09:57:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 09:57:47 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.e307045f3fb5de4e330860a34ab23e3e@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 Phyx-): The define shouldn't be needed, You need a newer glibc version to get the correct behaviour. It needs to be at least `2.23`. See https://ghc.haskell.org/trac/ghc/ticket/12147. The specific relocation can also only be generated by a ld > `2.26`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 10:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 10:03:35 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.46f3972b7904c4e214710905591f627f@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): HEAD * e054c5f064 (HEAD -> master, origin/master, origin/HEAD) Bump mtl, parsec, text submodules ben at smart-cactus.org 22 hours ago compiled with this build.mk also segfaults {{{ BuildFlavour = perf GhcRTSWays += debug GhcRTSWays += debug_p GhcRTSWays += thr_debug GhcRTSWays += thr_debug_p BUILD_DOCBOOK_HTML = YES ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif STRIP_CMD = : DYNAMIC_GHC_PROGRAMS = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 10:06:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 10:06:42 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.db3e868bc0e1f4f92a599d4cfec542b2@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): Btw, I'm not 100% sure how exactly version from comment #7 is compiled, using what compiler and so on as it wasn't done by me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 10:29:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 10:29:58 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.69cf9ec420dbf62f20a7a4a84d9df407@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): UPDATE: seems to be working fine with HEAD, so the only version affected is 8.2.1 downloaded and compiled with DYNAMIC_GHC_PROGRAMS = NO -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 11:28:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 11:28:12 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.887dde5b6f638830c3d55ff0ee3fd114@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 pacak): Actually... My bad again, HEAD segfaults after all just with lower probability. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 11:54:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 11:54:13 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.aa01d6f22cad22bccaf1d98401ad420f@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: 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 winter): * status: closed => new * resolution: wontfix => * milestone: Not GHC => 8.2.2 Comment: Today a friend asked me the exactly problem, i.e. why `iterate (+1) 1 !! 100000000` cost 8G ram. This is surprising because most people are expecting GC should chase the list and the whole computation should run in O(1) space. But as soon as i checked the definition of `iterate`, i realize it's no possible to run in O(1) space, we're simply not forcing the `f (f ... (f x))` chain at all. So i came to this ticket. Adding `iterate'` may not be enough: we have to add document to notify people to watch out! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 11:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 11:56:33 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD Message-ID: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails.That is while `./validate` passes. Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, @alanz also gets the similar result on his system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 11:57:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 11:57:20 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD In-Reply-To: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> References: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> Message-ID: <065.be69d5c9a46c7e68aa8d960b10780b4f@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Shayan-Najd: Old description: > In a freshly cloned GHC code base (c6462ab0...), in my system,`make test > TEST="T13780c T13822"` fails.That is while `./validate` passes. > > Specifically, I follow the following steps: > (1) `git clone --recursive git://git.haskell.org/ghc.git` > (2) `cd ghc` > (3) `cp mk/build.mk.sample mk/build.mk` > (4) set `BuildFlavour = devel2` and then > (5) ./boot > (6) ./configure > (7) make -j4 > (8) make test TEST="T13780c T13822" > > I build in a variant of the docker image for GHC development on Linux (64 > bit), if it matters. > > As it seems, @alanz also gets the similar result on his system. New description: In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails.That is while `./validate` passes. Specifically, I follow the following steps: 1. `git clone --recursive git://git.haskell.org/ghc.git` 2. `cd ghc` 3. `cp mk/build.mk.sample mk/build.mk` 4. set `BuildFlavour = devel2` and then 5. ./boot 6. ./configure 7. make -j4 8. make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, @alanz also gets the similar result on his system. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:01:17 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together Message-ID: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): corePrepPgm [True] $s$fSelectorMetaMetaSel_a = "_dconf_dump_annotations"# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:06:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:06:21 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans Message-ID: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- In a [https://github.com/shayan-najd/GrowableGHC branch] of GHC with [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Growable ASTs], the code compiles with `devel2` configuration, but fails with `./validate`. It passes all the test cases, except two that already fail in HEAD (see [https://ghc.haskell.org/trac/ghc/ticket/14126 #14126]). Especifically, the compiler returns the following error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170806 for x86_64-unknown-linux): ASSERT failed! HsPat [GHC.Base, GHC.Float, Data.Binary.Generic, Data.ByteString.Builder, HsBinds, HsDoc, HsExpr, HsLit, HsPat, HsTypes, PprCore, GHC.LanguageExtensions, Data.Time.Calendar.Gregorian, Data.Time.Format.Parse, Data.Time.LocalTime.Internal.LocalTime, Data.Time.LocalTime.Internal.ZonedTime] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/rename/RnNames.hs:364:99 in ghc:RnNames 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/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/rename/RnNames.hs:364:99 in ghc:RnNames Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I suspect (as hinted above) it has to do with a bug in the renamer when dealing with orphan instances (and probably in conjunction with boot files). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:24:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:24:18 -0000 Subject: [GHC] #14124: add shrink prim-op for other array type In-Reply-To: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> References: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> Message-ID: <060.31a0668ce0ba5272763b193cd3e7dcee@haskell.org> #14124: add shrink prim-op for other array type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't think it's quite as simple to provide a shrink operation for `MutableArray` and `MutableArrayArray` as it is for `MutableByteArray`. The reason is that in those cases we would need to remove the truncated references from the GC's remembered set. Of course, this ought to be doable, but it is a bit more complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:28:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:28:03 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.28147660da1461666808bb0d47b39ec6@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): If nothing else we should mention it in the migration guide. See [[Migration/8.4]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:31:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:31:36 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.0ee3c529aa5b4a431e404a9b3da82cc4@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: 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): Can you suggest some language? I would be happy to add it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:42:16 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO Message-ID: <044.348618562e66743b0480359855424811@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- ghc: HEAD {{{ module A where {-# ANN module "KABOOM" #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:48:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:48:18 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.88e93e571b8cfbd67b7f43579e90fb47@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): * status: new => infoneeded Comment: Can you post a minimal program which triggers this panic? I'm unable to construct one from the little info on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:48:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:48:42 -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.99bafb5d1ae62e203f22523558322194@haskell.org> #14089: Segmentation fault/access violation using Yesod and Postgresql ---------------------------------+-------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 RyanGlScott): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:51:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:51:39 -0000 Subject: [GHC] #14124: add shrink prim-op for other array type In-Reply-To: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> References: <045.da4e5351717e96d339b44d10fe4d25fe@haskell.org> Message-ID: <060.41b750ce1b647a6f658ee0109b1949c0@haskell.org> #14124: add shrink prim-op for other array type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I suppose a modification from `fold'` 's document is OK: -- | The strict version of 'iterate'. -- It ensures that each step of the iterating is forced to weak head normal form before next step, avoiding the collection of thunks that would otherwise occur. This is often what you want to strictly step a function which produces a single, monolithic result (e.g. (+1)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 12:52:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 12:52:30 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.ecfeb2223b7c7f8e696d3e9cd5a3c206@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I suppose a modification from `fold'` 's document is OK: -- | The strict version of 'iterate'. -- It ensures that each step of the iterating is forced to weak head normal form before next step, avoiding the collection of thunks that would otherwise occur. This is often what you want to strictly step a function which produces a single, monolithic result (e.g. (+1)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 13:20:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 13:20:38 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.e397b22673419ae2edfad3dbce49cfd1@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Good thought bgamari, I've [https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=4 added a blurb] about this to the 8.4 migration guide. I don't think it would hurt adding mention of the fact that `TypeInType`'s validity checks tightened up in the release notes. FWIW, there is [https://phabricator.haskell.org/D3859 another patch] in the works that will make `TypeInType` pickier w.r.t. GADTs as well, so it might also behoove us to mention that as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 13:27:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 13:27:16 -0000 Subject: [GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not In-Reply-To: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> References: <043.25eba9f4369a3feb11d0387308acf105@haskell.org> Message-ID: <058.7576176e8cef06d6d5c0e0099452d87e@haskell.org> #14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As I've been working on these patches, I haven't added anything to the release notes because they are bug-fixes, plain and simple. That said, the changes do make GHC accept fewer programs, so a note may be helpful to users. Thanks for adding this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 13:38:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 13:38:56 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.d7ebd4deeaefe286dc994734c7a1f150@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => high * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (FFI) Comment: From what I can see, there are two different bugs being reported here: 1. You can't use newtype instances as marshallable argument types. That is, this should compile, but doesn't: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Foreign.C.String import Foreign.C.Types data UnixReturn data family IOErrno a newtype instance IOErrno UnixReturn = UnixErrno CInt foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString }}} This is indeed a regression, as this code typechecks in 8.0.2 but not 8.2.1. I'll try to figure out which commit caused this. 2. You can't use newtypes as marshallable return types. However, I'm having trouble coming up with a minimal program which triggers the error you're claiming will happen on 8.2. I tried this: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Bug where import Foreign import Foreign.C.Types import System.Posix.Types newtype UnixReturn a = UnixReturn a foreign import ccall unsafe "recv" c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn CSsize) }}} But this typechecks on GHC 8.2, so there must be something that I'm missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 13:46:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 13:46:51 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.0ac4bbd43bc176e62d8179026f477f54@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Replying to [comment:74 jscholl]: I have been trying to write something similar down in https://github.com /ghc-proposals/ghc-proposals/compare/master...phadej:bytearray-literals It has a different syntax, which I think makes more sense than double- hash. Ben have given some comments already (they are inline in proposal text, so I remember them). He is worried about ByteArray#s code size, and I'm proposing similar "let's rewrite them to Addr# when possible" approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 13:50:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 13:50:05 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD In-Reply-To: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> References: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> Message-ID: <065.26910aa21e78532c881bf024ceb31b6c@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The failure in T13822 is fixed in Phab:3848. I don't know about the other one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 14:16:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 14:16:17 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.6cd975773a55622f15b442858430aad5@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have just sketched a different proposal here: https://ghc.haskell.org/trac/ghc/wiki/StaticData IMO it is more generic and the different parts can be implemented independently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 14:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 14:37:02 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.6c913bc88d5ca842c4b2cf9bd4ba308c@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 lspitzner): Sorry, I wrongly assumed this was much easier to reproduce. Now that I try, it appears to be pretty specific, in fact I can't even simplify properly. This still needs a dependency on aeson-1.2.1.0: - A.hs {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveDataTypeable #-} module A where import GHC.Generics data Foo = AltChooserSimpleQuick deriving (Generic) }}} - B.hs {{{#!hs {-# OPTIONS_GHC -fno-pre-inlining #-} {-# OPTIONS_GHC -fspecialise #-} {-# OPTIONS_GHC -fignore-interface-pragmas #-} module B where import A import qualified Data.Aeson.Types as Aeson instance Aeson.FromJSON Foo where parseJSON = Aeson.genericParseJSON Aeson.defaultOptions {-# NOINLINE parseJSON #-} }}} I have made several attempts to reproduce this with a standalone class instead of the one from aeson, but failed to do so. It also appears that the panic disappears when there is no orphan instance in play (i.e. if you merge modules A/B). Also note that simply replacing `data Foo = AltChooseSimpleQuick` with `data Foo = AltChoose` the panic disappears. Further testing suggests that it requires any constructor identifier with at least 21 characters to trigger the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 14:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 14:42:39 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.91eb31bdd3be9563f40086274f63a1d7@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #13877 => #13877, #14038 * blockedby: => 14119 Comment: After some analysis, I'm pretty sure this is #14038 again. Or, at least, that bug is preventing me from seeing this one clearly. Because #14038 is blocked by #14119, so is this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 14:47:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 14:47:57 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.789d0e11577dce27ff351f9fca9e9070@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 lspitzner): And now that I noticed this 21 character relevance, perhaps producing a standalone testcase without aeson is possible. But maybe it depends on some other random length of some textual representation or whatever? In that case creating a reliable smaller testcase might be a challenge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:02:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:02:21 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.6cf01bf33050de6e1f55fdeed130fc36@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Replying to [comment:84 hsyl20]: > I have just sketched a different proposal here: https://ghc.haskell.org/trac/ghc/wiki/StaticData > > IMO it is more generic and the different parts can be implemented independently. Note: Not all GHC have `TemplateHaskell`, especially stage 1 GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:06:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:06:58 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.068691617e2659c4ebaeacf498db3f32@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): To make things more interesting, I can reproduce this panic on GHC 8.0.2, but not on 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:29:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:29:32 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.48bd1bf71a43ff3dc735e226589a45e2@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => fixed Comment: After reading the source code some more, I believe this was properly fixed in GHC 8.2. Specifically, in commit d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 (Allow top-level string literals in Core (#8472)). That patch made the [http://git.haskell.org/ghc.git/blobdiff/a2a67b77c3048713541d1ed96ec0b95fb2542f9a..d49b2bb21691892ca6ac8f2403e31f2a5e53feb3:/compiler/coreSyn/CorePrep.hs following change]: {{{#!diff diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs index c93a121..fb650f6 100644 (file) --- a/compiler/coreSyn/CorePrep.hs +++ b/compiler/coreSyn/CorePrep.hs @@ -1168,7 +1168,9 @@ deFloatTop (Floats _ floats) = foldrOL get [] floats where get (FloatLet b) bs = occurAnalyseRHSs b : bs - get b _ = pprPanic "corePrepPgm" (ppr b) + get (FloatCase var body _) bs = + occurAnalyseRHSs (NonRec var body) : bs + get b _ = pprPanic "corePrepPgm" (ppr b) -- See Note [Dead code in CorePrep] occurAnalyseRHSs (NonRec x e) = NonRec x (occurAnalyseExpr_NoBinderSwap e) }}} Before, `get` was being called on a `FloatCase`, which is the only constructor that could have given the output `[True] $s$fSelectorMetaMetaSel_a = "_dconf_dump_annotations"#`. But now that this case is covered properly, the issue appears to have gone away. So I'll opt to close this issue, since I can't reproduce the problem on 8.2, and coming up with a minimal regression test doesn't seem feasible. Please feel free to re-open the issue if you come across the same panic on GHC 8.2 or later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:30:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:30:30 -0000 Subject: [GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together In-Reply-To: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> References: <048.019ba449d6fd854c71fc8bae844fe823@haskell.org> Message-ID: <063.68aa3366cd0bc80b53c21ce528f5a67b@haskell.org> #14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): thanks for looking into this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:39:18 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD In-Reply-To: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> References: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> Message-ID: <065.65dddec680e34f4d22a4d312732e0a49@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I can reproduce both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 15:48:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 15:48:59 -0000 Subject: [GHC] #13938: Iface type variable out of scope: k1 In-Reply-To: <050.7a3f2d444543ff2efcc9028549798245@haskell.org> References: <050.7a3f2d444543ff2efcc9028549798245@haskell.org> Message-ID: <065.fdca2654dd40c9e318ae8ccc712e5ddf@haskell.org> #13938: Iface type variable out of scope: k1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #14038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #14038 * blockedby: => 14119 Comment: This is, I'm pretty sure, #14038 again, and thus blocked by #14119. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 17:18:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 17:18:43 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.837a24f17c0a02b999f56d1896b42369@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: | -------------------------------------+------------------------------------- Comment (by ak3n): I am sorry, but what is the desired behaviour? I made a simple test with modules. The first module contains the drop function, while the second one calls it. At the current moment, both versions (ghc with the patch (D3566) and ghc 8.2.1) with enabled -O2 flag optimize the function with SpecConstr pass in the first module, and substitute the call to the optimized version into the second module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 17:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 17:49:26 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.e60417105eee5f39d145b1983cdac8cd@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) * milestone: => 8.2.2 Comment: So the commit that broke the program in item (1) in comment:2 is 3540d1e1a23926ce0a8a6ae83a36f5f6b2497ccf (`Avoid exponential blowup in FamInstEnv.normaliseType`). It's a fairly small commit, so I'm hoping that staring at the diff will reveal what changed to cause the program to go wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 18:09:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 18:09:10 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.046a10829dde2b7f0c54a964935d51b7@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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 diatchki): I don't mind if you close it---we now have type-nats of sorts, we can open future tickets for various improvements of them, if they are needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 18:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 18:29:44 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.730852a0047ae0011107476498c2c908@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | 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): OK. I've fixed this. Here is the new output: {{{ Pair :: TYPE rep -> TYPE rep' -> RuntimeRep -> * Pair Int :: * -> RuntimeRep -> * Pair Int Float :: RuntimeRep -> * Pair Int Float LiftedRep :: * }}} I'd say this is correct, because in the `Pair Int` case, we already have to choose the representation -- and we never regeneralize over `RuntimeRep` arguments. Patch will land with several others, in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 19:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 19:15:04 -0000 Subject: [GHC] #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType In-Reply-To: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> References: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> Message-ID: <063.ea94814c6aee27b4e0c29048725a0904@haskell.org> #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | TypeErrorMessages Operating System: 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): It's not clear to me the best way to fix this. It's tempting to suppress kind quantification with `-XNoTypeInType` and to suppress `forall` with `-XNoExplicitForAll`. But simply suppressing all these might sometimes give us the wrong type. For example, suppose we want `forall (b :: Bool). Proxy b`. Just saying `Proxy b` is plain wrong.... and it seems hard to know, a priori, when it would be wrong. Easier would be to print out the type as-is, but then look at it to determine whether the user might need extra extensions and suggest those, too.... but that's not as good a user experience. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 19:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 19:34:51 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.a21db6cabd97cf921322cb61b6c180d1@haskell.org> #4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Sounds good. Thanks yav! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 19:42:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 19:42:07 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.a516568199aeb3be8ca9b68507bbad87@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Question about these linters, I assume they scan the unified diff and not just the entire file? (I have my doubts as linting causes my laptop to heat up extensively). It seems to give lint errors for lines that weren't changed like https://phabricator.haskell.org/D3862. Is this expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 19:48:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 19:48:46 -0000 Subject: [GHC] #14130: MultiWayIf parse behavior changed in 8.2.1 Message-ID: <046.fe2af4fda3aaac1368a03ecbd964df23@haskell.org> #14130: MultiWayIf parse behavior changed in 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- I just noticed while working on Jenkins that ed7a830de6a2ea74dd6bb81f8ec55b9fe0b52f28 fails to build with GHC 8.0.1 with a parse error, yet succeeds with 8.2.1. The issue is demonstrated by the following program, {{{#!hs {-# LANGUAGE MultiWayIf #-} main = if | True -> putStrLn "hasdf" }}} Under GHC 8.0.1 this fails to compile with a parse error. Under 8.0.2 and 8.2.1 it parses without any trouble. We should sort out what the desired parse behavior for `MultiWayIf` is and add a test to ensure it doesn't change again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 19:51:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 19:51:05 -0000 Subject: [GHC] #14130: MultiWayIf parse behavior changed in 8.0.2 (was: MultiWayIf parse behavior changed in 8.2.1) In-Reply-To: <046.fe2af4fda3aaac1368a03ecbd964df23@haskell.org> References: <046.fe2af4fda3aaac1368a03ecbd964df23@haskell.org> Message-ID: <061.a5001eae6cdb4498b5718ddbc2564ef3@haskell.org> #14130: MultiWayIf parse behavior changed in 8.0.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Parser) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid * related: => #10807 Comment: Never mind; this was a false alarm. This change was intentional and due to #10807. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 20:12:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 20:12:23 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.0e1e4739734eb6ae8d8909ac39b6fe3b@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Comment (by Phyx-): New linker is making some significant progress here as well {{{ Tamar at Destiny MINGW64 /e/temp $ echo "main" | ~/ghc/inplace/bin/ghc-stage2.exe --interactive LLVM.hs $(llvm-config --libs --link-static) $(llvm-config --system-libs --link- static) -L/mingw64/lib/ -lstdc++ -lgcc GHCi, version 8.3.20170812: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( LLVM.hs, interpreted ) Ok, 1 module loaded. *Main> Access violation in generated code when reading ffffffffffffffff }}} The LLVM libraries require the new `big-obj` support and also require proper section alignment support which now works. The remaining problem is that it's C++ and requires proper support for Constructors and Destructors via `__DTOR_LIST__` and `__CTOR_LIST__`. However I lack some knowledge of how the C++ ABI and linking work so I'll need to read up before I can add this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 22:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 22:38:29 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.235d7bdd2e52b50fe94c8511207775ea@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3865 Comment: I've submitted a fix for (1) at Phab:D3865. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:02:36 -0000 Subject: [GHC] #7960: Compiling profiling CCS registration .c file takes far too long In-Reply-To: <045.c2642250b34d3cb777578b74c97e0226@haskell.org> References: <045.c2642250b34d3cb777578b74c97e0226@haskell.org> Message-ID: <060.fe45fa6c179766bda7c137165aa8ea61@haskell.org> #7960: Compiling profiling CCS registration .c file takes far too long -------------------------------------------------+------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Ben Gamari ): In [changeset:"a8da0de27e600211f04601ac737c329d6603c700/ghc" a8da0de2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8da0de27e600211f04601ac737c329d6603c700" Speed up compilation of profiling stubs Here we encode the cost centre list as static data. This means that the initialization stubs are small functions which should be easy for GCC to compile, even with optimization. Fixes #7960. Test Plan: Test profiling Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #7960 Differential Revision: https://phabricator.haskell.org/D3853 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:02:36 -0000 Subject: [GHC] #14130: MultiWayIf parse behavior changed in 8.0.2 In-Reply-To: <046.fe2af4fda3aaac1368a03ecbd964df23@haskell.org> References: <046.fe2af4fda3aaac1368a03ecbd964df23@haskell.org> Message-ID: <061.69ee48faaa5ac731759d6319b361f8ee@haskell.org> #14130: MultiWayIf parse behavior changed in 8.0.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Parser) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b0ed07fafbe96c3eee6c7f41ef937973bedbf1dc/ghc" b0ed07fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0ed07fafbe96c3eee6c7f41ef937973bedbf1dc" Allow TcDerivInfer to compile with GHC 8.0.1 As of ed7a830de6a2ea74dd6bb81f8ec55b9fe0b52f28 this module uses MultiWayIf, the parsing behavior of which changed in 8.0.2 due to #10807. Reformat the code so that it compiles under both 8.0.1 and 8.0.2/8.2.1. Test Plan: Validate bootstrapping with 8.0.1 Reviewers: austin Subscribers: rwbarton, thomie, RyanGlScott GHC Trac Issues: #14130 Differential Revision: https://phabricator.haskell.org/D3863 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:02:36 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.972b8174e685416103242416da13dab0@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b0ed07fafbe96c3eee6c7f41ef937973bedbf1dc/ghc" b0ed07fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0ed07fafbe96c3eee6c7f41ef937973bedbf1dc" Allow TcDerivInfer to compile with GHC 8.0.1 As of ed7a830de6a2ea74dd6bb81f8ec55b9fe0b52f28 this module uses MultiWayIf, the parsing behavior of which changed in 8.0.2 due to #10807. Reformat the code so that it compiles under both 8.0.1 and 8.0.2/8.2.1. Test Plan: Validate bootstrapping with 8.0.1 Reviewers: austin Subscribers: rwbarton, thomie, RyanGlScott GHC Trac Issues: #14130 Differential Revision: https://phabricator.haskell.org/D3863 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:07:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:07:40 -0000 Subject: [GHC] #7960: Compiling profiling CCS registration .c file takes far too long In-Reply-To: <045.c2642250b34d3cb777578b74c97e0226@haskell.org> References: <045.c2642250b34d3cb777578b74c97e0226@haskell.org> Message-ID: <060.5076c71aeefa933335a869f987e97520@haskell.org> #7960: Compiling profiling CCS registration .c file takes far too long -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:33:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:33:41 -0000 Subject: [GHC] #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS In-Reply-To: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> References: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> Message-ID: <065.d798b0b433d8519ad795eac61e58f68e@haskell.org> #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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): Phab:D3866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3866 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 16 23:37:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Aug 2017 23:37:10 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance Message-ID: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This works {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs #-} newtype Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} but this {{{#!hs {-# Language RankNTypes, PolyKinds, GADTs, TypeFamilies #-} data family Nat :: k -> k -> * newtype instance Nat :: (k -> *) -> (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} fails on GHC 8.3.20170815, and requires a `forall k.` to work {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/kind.hs GHCi, version 8.3.20170815: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/kind.hs, interpreted ) /tmp/kind.hs:5:26: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ /tmp/kind.hs:5:38: error: Not in scope: type variable ‘k’ | 5 | newtype instance Nat :: (k -> *) -> (k -> *) -> * where | ^ Failed, 0 modules loaded. }}} Related to #12369? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 00:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 00:34:53 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. Message-ID: <043.1281ae18d24cc16b799c87119536c685@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- The following code {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies, DataKinds #-} import GHC.Generics import GHC.TypeLits type family RepHasNoInstance (f :: * -> *) :: * -- edit 1 -- type instance RepHasNoInstance f = Int -- edit 2 -- class RepHasNoInstanceC (f :: * -> *) -- foo :: (Generic a, RepHasNoInstanceC (Rep a)) => a -> Int -- foo = const 1 foo :: (Generic a, RepHasNoInstance (Rep a) ~ Int) => a -> Int foo = const 1 data NotGeneric = NotGeneric bar :: NotGeneric -> Int bar = foo main :: IO () main = return () }}} gives an error like {{{ associated-type-families-test.hs:21:7: error: • Couldn't match type ‘RepHasNoInstance (Rep NotGeneric)’ with ‘Int’ arising from a use of ‘foo’ • In the expression: foo In an equation for ‘bar’: bar = foo | 21 | bar = foo | ^^^ }}} in ghcs: 8.0.2, 8.2.1, master(a few days old). The error message is for ambiguous types in 7.10.3 Uncommenting edit 1, the error changes to: {{{ associated-type-families-test.hs:16:7: error: • No instance for (Generic NotGeneric) arising from a use of ‘foo’ • In the expression: foo In an equation for ‘bar’: bar = foo | 16 | bar = foo | }}} I think this is a much better error message, since there is no hope for the associated type to have an instance for anything unless there is an instance (Generic NotGeneric). Uncommenting edit 2, (and commenting the existing foo) gives the "No instance for (Generic NotGeneric)" message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 01:38:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 01:38:39 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.ae9145b9e47dcf3b1a73bf5f207fba78@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3867 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 01:41:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 01:41:56 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.84c531f5461f5b3be2f5094d81933a5c@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 03:54:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 03:54:13 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.adc699dc08962d78d6dba150a69bc35a@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Well, the second case is very easy to create, just use newtype instance: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ForeignFunctionInterface #-} module Bug where import Foreign import Foreign.C.Types import System.Posix.Types class IOReturn (r :: * -> *) where -- | The errno type associated with 'r' data IOErrno r :: * newtype UnixReturn a = UnixReturn a instance IOReturn UnixReturn where newtype IOErrno UnixReturn = UnixErrno CInt foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) }}} {{{ [1 of 1] Compiling Bug ( Main.hs, Main.o ) Main.hs:20:1: error: • Unacceptable result type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | 20 | foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 11:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 11:47:52 -0000 Subject: [GHC] #14133: COMPLETE pragmas seem to be ignored when using view patterns Message-ID: <042.4894eb4567784f0c7c1ffe7cd1e58e5e@haskell.org> #14133: COMPLETE pragmas seem to be ignored when using view patterns -------------------------------------+------------------------------------- Reporter: jle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} pattern I :: Int -> Int pattern I x <- (id -> x) {-# COMPLETE I #-} foo :: Int -> Int foo (I x) = x + 3 bar :: Int -> Int bar (id->I x) = x + 3 main :: IO () main = return () }}} Raises a warning for `bar`: {{{ Bug.hs:12:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for 'bar': Patterns not matched: _ | 12 | bar (id->(I x)) = x + 3 | ^^^^^^^^^^^^^^^^^^^^^^^ }}} but not for `foo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 11:51:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 11:51:28 -0000 Subject: [GHC] #14133: COMPLETE pragmas seem to be ignored when using view patterns In-Reply-To: <042.4894eb4567784f0c7c1ffe7cd1e58e5e@haskell.org> References: <042.4894eb4567784f0c7c1ffe7cd1e58e5e@haskell.org> Message-ID: <057.f7de3851b533493513122476c02bf4db@haskell.org> #14133: COMPLETE pragmas seem to be ignored when using view patterns -------------------------------------+------------------------------------- Reporter: jle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jle: Old description: > {{{#!hs > {-# LANGUAGE ViewPatterns #-} > {-# LANGUAGE PatternSynonyms #-} > > pattern I :: Int -> Int > pattern I x <- (id -> x) > {-# COMPLETE I #-} > > foo :: Int -> Int > foo (I x) = x + 3 > > bar :: Int -> Int > bar (id->I x) = x + 3 > > main :: IO () > main = return () > }}} > > Raises a warning for `bar`: > > {{{ > Bug.hs:12:1: warning: [-Wincomplete-patterns] > Pattern match(es) are non-exhaustive > In an equation for 'bar': Patterns not matched: _ > | > 12 | bar (id->(I x)) = x + 3 > | ^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > but not for `foo`. New description: {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} pattern I :: Int -> Int pattern I x <- (id -> x) {-# COMPLETE I #-} foo :: Int -> Int foo (I x) = x + 3 bar :: Int -> Int bar (id->I x) = x + 3 main :: IO () main = return () }}} Raises a warning for `bar`: {{{ Bug.hs:12:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for 'bar': Patterns not matched: _ | 12 | bar (id->I x) = x + 3 | ^^^^^^^^^^^^^^^^^^^^^^^ }}} but not for `foo`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 12:43:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 12:43:13 -0000 Subject: [GHC] #14133: COMPLETE pragmas seem to be ignored when using view patterns In-Reply-To: <042.4894eb4567784f0c7c1ffe7cd1e58e5e@haskell.org> References: <042.4894eb4567784f0c7c1ffe7cd1e58e5e@haskell.org> Message-ID: <057.c4f7c21635fc16c7443030bb1a5be783@haskell.org> #14133: COMPLETE pragmas seem to be ignored when using view patterns -------------------------------------+------------------------------------- Reporter: jle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternSynonyms, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 12:44:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 12:44:15 -0000 Subject: [GHC] #14134: Implement enums for Cmm Message-ID: <046.d60496259b348d3562044d876e1e8182@haskell.org> #14134: Implement enums for Cmm -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: (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: -------------------------------------+------------------------------------- Using ANSI C enums is documented as a preferred way of defining constants: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Conventions#Syntacticdetails Basically instead of writing: {{{ #define INVALID_OBJECT 0 #define CONSTR 1 }}} you would write: {{{ typedef enum { INVALID_OBJECT = 0, CONSTR = 1 } ClosureType; }}} What you get is easier debugging in gdb, perhaps even better type checking. Unfortunately some files (most vexingly `rts/storage/ClosureTypes.h`) are included in both C and Cmm and Cmm doesn't support this syntax. As far as I can tell all constants in Cmm are defined with preprocessor `#define`s. Implementing enums/constants may seem like an overkill, but I haven't found a good workaround for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 12:48:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 12:48:09 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.e87b1823c8371537f0b3f76d74498829@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, I already have a test case for `IOErrno UnixReturn` in the Diff posted earlier (whether it's an argument type or result type isn't of much consequence, as they're normalized the same). To be clear, I was inquiring about this code from your original post. {{{#!hs foreign import CALLCONV unsafe "HsNet.h recv" c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn CSsize) }}} I am unable to get this code to emit a `Unacceptable result type in foreign declaration` warning on GHC 8.2 like you claimed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 13:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 13:37:41 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.f33f9cc5a5ae70052ce84f13f861634b@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No. Not really related to #12369. Perhaps related to #13985. Perhaps not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 13:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 13:40:27 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.407a765a53707bb2d1994d0e0d27097d@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): My bad, I checked the orignal console output, and the problem just occurs when newtype instance involved. The original output is here: https://travis- ci.org/winterland1989/stdio/jobs/264713243 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:02:55 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.6a32ffcc880ed9eec6d351100fb58e36@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Gotcha, thanks for confirming. To be on the safe side, I've updated the Diff to include a test that uses `IOErrno UnixReturn` as a return type as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:16:29 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.3a8125d38aef7fc25d2c1c1d7a4b3824@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Phab:D3851 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"039fa1b994a8b0d6be25eb1bc711904db9661db2/ghc" 039fa1b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="039fa1b994a8b0d6be25eb1bc711904db9661db2" Suggest how to fix illegally nested foralls in GADT constructor type signatures Summary: Although the code from #12087 isn't accepted by GHC, we can at least do a better job of letting users know what the problem is, and how to fix it. Test Plan: make test TEST=T12087 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #12087 Differential Revision: https://phabricator.haskell.org/D3851 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:16:29 -0000 Subject: [GHC] #13972: GHC 8.2 error message around indexes for associated type instances is baffling In-Reply-To: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> References: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> Message-ID: <065.a2e561dfacc9cb37c0e381a36d3a0f0b@haskell.org> #13972: GHC 8.2 error message around indexes for associated type instances is baffling -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeFamilies, Resolution: | 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): Phab:D3820 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"38260a9e9f8c38edd25f4b4c06e0ea5d88fc6bf2/ghc" 38260a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38260a9e9f8c38edd25f4b4c06e0ea5d88fc6bf2" Fix #13972 by producing tidier errors Summary: Previously, one could experience an error message like this: ``` Expected: T (a -> Either a b) Actual: T (a -> Either a b) ``` This makes the error message an iota clearer by tidying it first, which will instead produce: ``` Expected: T (a1 -> Either a1 b1) Actual: T (a -> Either a b) ``` Which steers users towards the understanding that the two sets of tyvars are actually different. Test Plan: make test TEST=T13972 Reviewers: simonpj, austin, bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13972 Differential Revision: https://phabricator.haskell.org/D3820 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:16:29 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.b44f215b07906491f4699d1bcfefa57f@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | 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:D3751, Wiki Page: | Phab:D3854 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"c948b7865ace38d3d6912db0fc271aa7e9f70d2b/ghc" c948b786/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c948b7865ace38d3d6912db0fc271aa7e9f70d2b" Fix #11785 by making reifyKind = reifyType Summary: This ties up the last loose end in Template Haskell's separate code paths for types and kinds. By making `reifyKind = reifyType` in `TcSplice`, types and kinds are now treated on equal terms in TH. This is itself a small patch, but most of the heavy lifting to make this possible was done in ad7b945257ea262e3f6f46daa4ff3e451aeeae0b. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #11785 Differential Revision: https://phabricator.haskell.org/D3854 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:18:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:18:25 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.ea951e642cfb838307ac667afd4216c3@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T12087 Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Phab:D3851 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => gadt/T12087 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:19:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:19:32 -0000 Subject: [GHC] #13972: GHC 8.2 error message around indexes for associated type instances is baffling In-Reply-To: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> References: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> Message-ID: <065.5cfe7f97473b84d2884f372e0e60d09e@haskell.org> #13972: GHC 8.2 error message around indexes for associated type instances is baffling -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeFamilies, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: indexed- error message | types/should_fail/T13972 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3820 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => indexed-types/should_fail/T13972 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 14:20:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 14:20:47 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.211784b1e3ce74ecda10d1806c072279@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.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): Phab:D3751, Wiki Page: | Phab:D3854 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 15:59:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 15:59:21 -0000 Subject: [GHC] #13902: Misleading function arity mismatch error with TypeApplications In-Reply-To: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> References: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> Message-ID: <065.c98cb8ee4e12fd500f393ad0b1e83cd4@haskell.org> #13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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:D3868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:10:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:10:06 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.6a400bcc9e220d3d3f2774178d8e18cc@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12031 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joeyhess): With ghc 8.0.2, I'm seeing 2500 ENOENTS. That is a large improvement from before, but still expensive. It adds around 200 ms to the startup time. My program is linked dynamically with 203 haskell libraries, and there are a dozen paths still in RPATH for the libraries bundled with ghc. So, while there are only a few bundled libraries, their RPATHs still multiply badly with the often large numbers of libraries used by haskell programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:43:05 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.1e4aceceeef7cfab4690f29d310f8957@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"03327bf049acb595c3ba034d16ee5bd0afabe7c4/ghc" 03327bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03327bf049acb595c3ba034d16ee5bd0afabe7c4" Handle ListPat in isStrictPattern This fixes #14105. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:43:05 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument In-Reply-To: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> References: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> Message-ID: <061.6dbb9a9a4448c7cb8d035c65a31f9d6f@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: ocheron Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: integer-gmp 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:D3826 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c5605ae00e9bff90db7a5f24ff3b8de2aba3b55b/ghc" c5605ae0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5605ae00e9bff90db7a5f24ff3b8de2aba3b55b" Make function intToSBigNat# preserve sign (fixes #14085) Impacts only functions gcdExtInteger, powModInteger and recipModInteger which gave invalid results on negative S# inputs. Also fixes gcdExtInteger assertion when first argument is negative. Test Plan: Updated test case integerGmpInternals Reviewers: austin, hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14085 Differential Revision: https://phabricator.haskell.org/D3826 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:43:05 -0000 Subject: [GHC] #11975: New GHCi command to print out the type of an expression without instantiating In-Reply-To: <047.e04c32cf521defebb6ebe9369a8011c1@haskell.org> References: <047.e04c32cf521defebb6ebe9369a8011c1@haskell.org> Message-ID: <062.e40d782b99e585d36dfd16f2750a8af2@haskell.org> #11975: New GHCi command to print out the type of an expression without instantiating -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11975 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"82ee71fa85aca087b2cd62cb354fc3df46db4411/ghc" 82ee71f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="82ee71fa85aca087b2cd62cb354fc3df46db4411" user-guide: add `:type +d` and `:type +v` in release highlight Add new ghci command to release highlight and fix link anchor. This commit is for ghc-8.2 branch. Test Plan: build Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11975 Differential Revision: https://phabricator.haskell.org/D3850 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:43:05 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.9495dc919a4417ef899c081cec9f79e0@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): Phab:D3860 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dc42c0dc91e29ca0eba3ee299f5feba03e401483/ghc" dc42c0dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc42c0dc91e29ca0eba3ee299f5feba03e401483" Fix #13399 by documenting higher-rank kinds. Test Plan: Read it. Reviewers: simonpj, RyanGlScott, austin, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, thomie GHC Trac Issues: #13399 Differential Revision: https://phabricator.haskell.org/D3860 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 20:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 20:43:05 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.9c955cd3c92c741c7bae86b1706f8208@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: fixed | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"02862140ee3fee6e522f0d73a1ac14e6cf29e501/ghc" 02862140/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02862140ee3fee6e522f0d73a1ac14e6cf29e501" testsuite: Add test for #13916 Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3764 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 22:10:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 22:10:56 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.70c98256ead7a795431da9eeccea0bf3@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that this error does not occur if the kind variables are bound in an earlier type pattern. That is, this equivalent instance typechecks: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} data family Nat :: k -> k -> * newtype instance Nat (f :: k -> *) :: (k -> *) -> * where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 22:29:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 22:29:11 -0000 Subject: [GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families In-Reply-To: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> References: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> Message-ID: <065.973238ca5aa14449edec43c91f2344da@haskell.org> #13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269, #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: #11962 => #9269, #11962 Comment: This is a duplicate of #9269. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 22:30:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 22:30:02 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.559a64dc69eda83e24003db4d88e4b42@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11962 Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * blocking: => 11962 * related: => #13901 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 22:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 22:58:13 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.9520490a693353b4b9fe3a0a7787ccf0@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After tinkering around with this example some more, I realized that the problem isn't limited to just data family instances—this affects type families across the board. Namely, type families do not implicitly bind kind variables that users write in result signatures. That is, this type synonym definition is legal: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} type F = (Nothing :: Maybe a) }}} But this type family instance is not legal: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} type family F :: Maybe a type instance F = (Nothing :: Maybe a) }}} {{{ GHCi, version 8.3.20170816: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:6:37: error: Not in scope: type variable ‘a’ | 6 | type instance F = (Nothing :: Maybe a) | ^ }}} I don't see any reason why the latter definition should be rejected. One could object that all the type variables in a type family instance must be bound on the LHS type patterns. But really, the `a` is `Maybe a` is bound by the often-neglected //RHS// type pattern. This is made more evident by the fact that tweaking the code to avoid the explicit `Maybe a` kind ascription makes it typecheck: {{{#!hs type instance F = Nothing }}} However, if you inspect `F` with `:info` in GHCi with the `-fprint- explicit-kinds` flag enabled, then you discover that you end up achieving the same result in the end: {{{ λ> :set -fprint-explicit-kinds λ> :i F type family F a :: Maybe a -- Defined at Bug.hs:5:1 type instance F a = 'Nothing a -- Defined at Bug.hs:6:15 }}} Here, it becomes evident that the kind variable `a` in `Maybe a` is being implicitly bound. But alas, GHC won't let you write it out explicitly. This becomes even more infuriating when dealing with associated type instances. For example, I tried to write this: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} class C k where type T :: k instance C (Maybe a) where type T = (Nothing :: Maybe a) }}} {{{ GHCi, version 8.3.20170816: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:3: error: The RHS of an associated type declaration mentions ‘a’ All such variables must be bound on the LHS | 9 | type T = (Nothing :: Maybe a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Once again, GHC mistakenly assumes that `a` must be bound in a LHS type pattern. But the whole point of `T` is that the instance is determined by the RHS type pattern! So as a workaround, I must leave off the explicit kind signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 17 23:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Aug 2017 23:58:32 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) Message-ID: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code works in GHC 8.2: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Bug where data Foo a = Foo1 a | Foo2 a pattern MyFoo2 :: Int -> Foo Int pattern MyFoo2 i = Foo2 i {-# COMPLETE Foo1, MyFoo2 #-} f :: Foo a -> a f (Foo1 x) = x }}} But it throws a compile-time exception on GHC HEAD: {{{ $ ghc3/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): expectJust mkOneConFull CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:53:27 in ghc:Maybes expectJust, called at compiler/deSugar/Check.hs:1128:37 in ghc:Check }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 00:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 00:00:11 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.d3b41945f9a2401478d2b5ac32072760@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms 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): * version: 8.2.1 => 8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 00:12:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 00:12:12 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.b58caee839b257da565064490f0ed985@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11962 Related Tickets: #13901 | 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 Fri Aug 18 00:34:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 00:34:40 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.b8efe1fd3c85358dce0125df4541a70f@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms 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: simonpj (added) Comment: Commit 6b77914cd37b697354611bcd87897885c1e5b4a6 (`Fix instantiation of pattern synonyms`) is responsible for this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 05:42:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 05:42:09 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.418483b5e2c35ee623443f54fe6ee606@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11962 Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 10:05:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 10:05:51 -0000 Subject: [GHC] #14136: Unsupported unicode characters crashes the program Message-ID: <045.ea42a2642589f34989f2dc5c050e71bb@haskell.org> #14136: Unsupported unicode characters crashes the program --------------------------------------+---------------------------------- Reporter: remote | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- If the terminal does not support a character, the program will crash if you try to display it. {{{#!hs main = putStrLn "ms{\2205}" }}} *Lib> main ms{*** Exception: : hPutChar: invalid argument (invalid character) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 10:53:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 10:53:45 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points Message-ID: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In pursuing #14068, [https://phabricator.haskell.org/D3811#107745 Joahim says] found this code: {{{ let { ds5 :: [[Int]] ds5 = case ==# x1 ww1 of { __DEFAULT -> go1 (+# x1 1#); 1# -> n } } in join { lvl6 :: [[Int]] lvl6 = (ds4 : y) : ds5} in joinrec { safe :: Int -> Int -> [Int] -> [[Int]] safe (x2 :: Int) (d :: Int) (ds6 :: [Int]) = case ds6 of { [] -> jump lvl6; : q l -> case x2 of wild6 { I# x3 -> case q of { I# y1 -> case /=# x3 y1 of { __DEFAULT -> ds5; 1# -> case d of { I# y2 -> case /=# x3 (+# y1 y2) of { __DEFAULT -> ds5; 1# -> case /=# x3 (-# y1 y2) of { __DEFAULT -> ds5; 1# -> jump safe wild6 (I# (+# y2 1#)) l }}}}}} }; } in jump safe ds4 lvl y; } in ... }}} This is terrible! `lvl6` is a join point, but `ds5` is not. And it's easy to fix: we should simply float `ds5` into `lvl6`'s rhs. **Backgound**. In general, if GHC sees this {{{ -- Version A x = f x : g y }}} it'll float out the `(f x)` and `(g y)` parts thus (B): {{{ -- Version B a1 = f x a2 = g y x = a1 : a2 }}} Reasons: 1. In the scope of this binding we might have `case x of (a:b) -> rhs`, and the new form allows us to eliminate the case. 2. Version A builds a thunk (which, when eval'd) builds thunks for `(f x)` and `(g y)` and returns a cons; whereas Version B builds the two thunks ahead of time and allocates a cons directly. If `x` gets evaluated this is a win, by avoiding an extra thunk. We measured this in our let- floating paper, and B is much better on average. But if `x` is a join point, all this is wrong wrong wrong: 1. A join point is never scrutinised by a nested case, so there is no benefit in floating. 2. A join point is not implemented by a thunk, so there is no thunk alloc/update to avoid. In fact, for join points we want to turn Version B into Version A! Specifically: * In `Simplify`, do not call `prepareRhs` on join RHSs; nor do floating (see `tick LetFloatFromLet`) from the RHS of a join. In fact this seems to be already the case. * In `OccurAnal`, do not use `rhsCtxt` for the RHS of a non-recursive join point (see `occAnalNonRecRhs`). Setting this context makes `a1` and `a2` get "inside-lam" occurrences (see `occAnalApp`), and that in turn stops `a1` and `a2` getting inlined straight back into `x`'s RHS in Version B. But for join points we **want** them to be inlined, to get back to Version A. For a recursive join point we probably do not want to inline `a1` and `a2` because then they'd be allocated each time round the loop. But in fact we can't have a recursive join point whose RHS is just a cons, so it doesn't really arise. The point is: we only need to take care with `rhsCtxt` for non-recursive join points. Bottom line: just that one fix to `OccurAnal` should do the job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 10:55:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 10:55:22 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.a16c900f1111081ef5d80493a2272ea6@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 11:18:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 11:18:34 -0000 Subject: [GHC] #14136: Unsupported unicode characters crashes the program In-Reply-To: <045.ea42a2642589f34989f2dc5c050e71bb@haskell.org> References: <045.ea42a2642589f34989f2dc5c050e71bb@haskell.org> Message-ID: <060.d009c3701eb44ddd807b55cc678d3e29@haskell.org> #14136: Unsupported unicode characters crashes the program ----------------------------------+-------------------------------------- Reporter: remote | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #11394 Comment: Thanks for the report, this is another manifestation of #11394. It happens because we unfortunately don't use native Windows APIs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 12:22:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 12:22:01 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.cb05fff70e8e807999ea2a5042099e97@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > One implementation strategy that doesn't involve mucking about with HPT retypechecking is to somehow make the typechecker aware of what unfoldings it should "see" and which it should not. This is reminiscent of #9370 (see comment 20 and following). I don't know how tight the linkage is. BTW did your really mean "make the typechecker aware"? It's the simplifier that is doing more inlining than it should, isn't it? (Not the typechecker.) And how much does all this matter anyway? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 12:32:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 12:32:47 -0000 Subject: [GHC] #14100: Nested NPlusKPatterns In-Reply-To: <043.ebbdad8e4d064c94fc61b26ef660bc7d@haskell.org> References: <043.ebbdad8e4d064c94fc61b26ef660bc7d@haskell.org> Message-ID: <058.1df6b900408975edefa83522a72cde70@haskell.org> #14100: Nested NPlusKPatterns -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Nested patterns involving NPlusKPatterns cause a "parse error in > pattern". Example appended below. > > > {-# LANGUAGE NPlusKPatterns #-} > > {-# LANGUAGE ViewPatterns, PatternSynonyms #-} > > > infix 1 :^: > > > > data Bush elem = Nil | Bud elem | Bush elem :^: Bush elem > > > test ((n + 1) + 1) = n > > > pattern DivMod2 ∷ (Integral nat) ⇒ nat → nat → nat > > pattern DivMod2 n k ← ((`divMod` 2) → (n, k)) where DivMod2 n k = 2 * > n + k > > > braun ∷ Integer → Bush () > > braun (0) = Nil > > braun (1) = Bud () > > braun (DivMod2 n k + 2) = braun (n + k + 1) :^: braun (n + 1) New description: Nested patterns involving NPlusKPatterns cause a "parse error in pattern". Example appended below. {{{ > {-# LANGUAGE NPlusKPatterns #-} > {-# LANGUAGE ViewPatterns, PatternSynonyms #-} > infix 1 :^: > > data Bush elem = Nil | Bud elem | Bush elem :^: Bush elem > test ((n + 1) + 1) = n > pattern DivMod2 ∷ (Integral nat) ⇒ nat → nat → nat > pattern DivMod2 n k ← ((`divMod` 2) → (n, k)) where DivMod2 n k = 2 * n + k > braun ∷ Integer → Bush () > braun (0) = Nil > braun (1) = Bud () > braun (DivMod2 n k + 2) = braun (n + k + 1) :^: braun (n + 1) }}} -- Comment (by simonpj): Fair point. However, Haskell 98 insists on a variable to the left of the `+`. Here's the [https://www.haskell.org/onlinereport/exps.html Haskell 98 report]: look in 3.17.1. n+k patterns were removed in later versions of Haskell (Haskell 2010 I think) but GHC still supports them. It think it's unlikely we'll elaborate them, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 12:37:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 12:37:23 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.8d2196a082b6a6c5691cac566ae1c1ee@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): George, any progress? Everyone: George is now doing many other things. Would anyone like to step up to looking after the patterm-match overlap checker? It's a thing of some beauty but needs love. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 12:48:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 12:48:58 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.6cb96b86d8279c2d337d13c005ec53a9@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12494.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:08:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:08:07 -0000 Subject: [GHC] #14106: Out of scope errors appear after type errors caused by them In-Reply-To: <048.46cf54e7237868a679805e12487d844f@haskell.org> References: <048.46cf54e7237868a679805e12487d844f@haskell.org> Message-ID: <063.a3c7b41082dd4d00be81df78419686e6@haskell.org> #14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Example: > > import Control.Lens (_Just, (&)) > main = Just 5 & _Just .~ 100 & print > > .~ is out of scope, the error output: > > ghc-error.hs:2:17-21: error: … > • Couldn't match type ‘Maybe’ with ‘p0 a0’ > Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) > Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) > • In the second argument of ‘(&)’, namely ‘_Just’ > In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ > In the expression: (.~) Just 5 & _Just 100 & print > ghc-error.hs:2:23-24: error: … > • Variable not in scope: > (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t > • Perhaps you meant ‘.’ (imported from Prelude) > Perhaps you want to add ‘.~’ to the import list in the import of > ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). > Compilation failed. > > In larger examples, the out of scope error can be buried deep down. > > In the case of operators - the fixity is unknown so it can even cause the > parse to go wrong - and very weird type errors to result from that. > > Out of scope errors should be put BEFORE any type errors that might be > caused by them. New description: Example: {{{ import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print }}} .~ is out of scope, the error output: {{{ ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed. }}} In larger examples, the out of scope error can be buried deep down. In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that. Out of scope errors should be put BEFORE any type errors that might be caused by them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:11:26 -0000 Subject: [GHC] #14106: Out of scope errors appear after type errors caused by them In-Reply-To: <048.46cf54e7237868a679805e12487d844f@haskell.org> References: <048.46cf54e7237868a679805e12487d844f@haskell.org> Message-ID: <063.ab815e1d0f39ac7d4a3351e29c201ad3@haskell.org> #14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I do rather agree. Currently, GHC * Suppresses warnings if there are any errors * Sorts errors/warnings by line number Better, I think, would be * Sort all messages by severity, most severe first * Then, within severity, by line number * Ensure that out-of-scope errors are somehow more severe There are hooks for all this: all messages have a line number and a severity. But it's not terribly well structured or described, so it might take a bit of careful work to implement this ideas. Nothing actually difficult, though. Volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:17:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:17:16 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.3df718677182889ad0ab87c28b40eeb8@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > meaning that commit fixes the underlying problem. So can we close this ticket? Or is there still a problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:36:58 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.c1d91503bc7a90d0b61fc499b59701e5@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:46:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:46:12 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.f44f56ee3037daa5670f96df45fb5877@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | 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): Phab:D3860 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Old description: > The following code fails to compile, but probably should: > > {{{ > {-# LANGUAGE RankNTypes, TypeInType #-} > > import Data.Kind > > data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 > > class C (a :: forall k . k -> *) > > instance C (Foo a) -- error on this line > }}} > > with the error > > {{{ > • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ > • In the first argument of ‘C’, namely ‘Foo a’ > In the instance declaration for ‘C (Foo a)’ > }}} > > Similarly, the following declarations of `Foo` also cause a similar error > at the instance declaration: > > Decl 2: `data Foo :: (* -> *) -> k -> *` > > Decl 3: `data Foo (a :: * -> *) (b :: k)` > > However, if I move the `forall` to a point ''after'' the first type > parameter (which is where the instance is partially applied) thusly: > > Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` > > then GHC happily accepts the instance of `C`. > > From my (admittedly negligible) knowledge of type theory, the signatures > for Decls 1 and 4 (and 2) are identical, since the `forall` can be > floated to the front of Decl 4. GHC should accept any of the four > versions of `Foo`, since they are all equivalent. New description: The following code fails to compile, but probably should: {{{#!hs {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 class C (a :: forall k . k -> *) instance C (Foo a) -- error on this line }}} with the error {{{ • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ • In the first argument of ‘C’, namely ‘Foo a’ In the instance declaration for ‘C (Foo a)’ }}} Similarly, the following declarations of `Foo` also cause a similar error at the instance declaration: Decl 2: `data Foo :: (* -> *) -> k -> *` Decl 3: `data Foo (a :: * -> *) (b :: k)` However, if I move the `forall` to a point ''after'' the first type parameter (which is where the instance is partially applied) thusly: Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` then GHC happily accepts the instance of `C`. From my (admittedly negligible) knowledge of type theory, the signatures for Decls 1 and 4 (and 2) are identical, since the `forall` can be floated to the front of Decl 4. GHC should accept any of the four versions of `Foo`, since they are all equivalent. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:46:29 -0000 Subject: [GHC] #14085: powModInteger sometimes ignores sign of argument In-Reply-To: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> References: <046.f3b5ae942b04675df860b692ad2aece3@haskell.org> Message-ID: <061.83bd00b3fa8f0aadfc334ba09caeb0f7@haskell.org> #14085: powModInteger sometimes ignores sign of argument -------------------------------------+------------------------------------- Reporter: ocheron | Owner: ocheron Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.2.1 Resolution: fixed | Keywords: integer-gmp 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:D3826 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:51:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:51:30 -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.8fb7d31546a6bba68e427e188e99dd55@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6257fb528c1c92fbe3bd66441bfba00f632d1b50/ghc" 6257fb5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6257fb528c1c92fbe3bd66441bfba00f632d1b50" Comments about GlobalRdrEnv shadowing Provoked by Trac #14052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:51:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:51:30 -0000 Subject: [GHC] #14110: GHC Panic on over-saturated associated type family In-Reply-To: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> References: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> Message-ID: <066.28c4bbe58c6f7850fd96d399480d1ba8@haskell.org> #14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"61c42464d2f128403e2cd082b5c74f0dd7890452/ghc" 61c4246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="61c42464d2f128403e2cd082b5c74f0dd7890452" Test Trac #14110 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:53:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:53:48 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.643fb0c4250bca0f9ce52d143a97c50e@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I added the join-point related line here: {{{ occAnalNonRecRhs env bndr bndrs body = occAnalLamOrRhs rhs_env bndrs body where -- See Note [Cascading inlines] env1 | certainly_inline = env | Just _ <- willBeJoinId_maybe bndr = env | otherwise = rhsCtxt env }}} to set `env` instead of `rhsCtxt`, and verified that it matches `lvl6` in the example above. But it did not cause any effect. (The desired effect would be that `ds5` gets inlined into `lvl6`, so that the remaining uses of `ds5`, all in `joinrec safe`, are tail-calls and `ds5` gets turned into a join point. Right?) I am attaching the Haskell’ification of the source code above that I was using for testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:55:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:55:42 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.6fcabec0265a368d45a77990df6a6a38@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I get an trac error when attaching files, so here it is: {{{ module T14137 where foo x ds4 n = safe x ds4 where ds5 :: [[Int]] ds5 = if x == 0 then foo (x-1) ds4 n else n lvl6 :: [[Int]] lvl6 = (x : ds4) : ds5 safe :: Int -> [Int] -> [[Int]] safe x2 ds6 = case ds6 of [] -> lvl6; q : l | x2 == q -> ds5 | x2 + 1 == q -> ds5 | x2 + 2 == q -> ds5 | x2 + 3 == q -> ds5 | otherwise -> safe (x+10) l }}} (I did not simply create a test case directly because I need to see the actualy, desired output in order to write the check.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:56:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:56:17 -0000 Subject: [GHC] #14110: GHC Panic on over-saturated associated type family In-Reply-To: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> References: <051.1263d9a5acf3e7421486ab720a352305@haskell.org> Message-ID: <066.21b549716bb6cc6477747e9281329888@haskell.org> #14110: GHC Panic on over-saturated associated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack 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: | polykinds/T14110 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14110 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 13:58:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 13:58:44 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.a5c412bd45d023072d2a0f5c343cb1d7@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): {{{ | Just _ <- willBeJoinId_maybe bndr = env }}} I think `isJoinId` would be fine, and much faster. > (The desired effect would be that ds5 gets inlined into lvl6, so that the remaining uses of ds5, all in joinrec safe, are tail-calls and ds5 gets turned into a join point. Right?) Not quite: `ds5` won't be a join point; it'll disappear entirely by being inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:08:27 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.f34deb5d26244f9146668ee40880e9c0@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I think `isJoinId` would be fine, and much faster. Isn’t it the simplifier that turns a potential join point into one? So if I use `isJoinId`, won’t this delay the effect of the patch to the first run off the occurrence analyser after a simplifier run, instead of doing it right in the first occurrence analyzer run? (`tagNonRecBinder` only modifies the `idOccInfo`). > Not quite: ds5 won't be a join point; it'll disappear entirely by being inlined. What about the many occurrences of `ds5` in `safe`? Don’t they prevent inlining, due to code duplication? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:15:18 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.9bb31231ce91b7a6451e1c92442934d4@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why do you say > This is a serious regression After all, if no one mentions a static expression then it's dead isn't it? I didn't even know about `staticPtrKeys`! The [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #static-pointers user manual section] does not mention it. Where are all the functions available on static pointers defined? Facundo has put a lot of work into static pointers, and I'm pretty sure that some of it is not reflected in this section. E.g. the user manual doesn't even mention the type `StaticKey`. This is worth fixing! It's not a bug if the specification (i.e. the user manual) doesn't claim it is so. Returning to the current topic, suppose we have {{{ foo = ...lots of code...(static reverse)....lots more code... }}} do you really want that `(static reverse)` to be accessible to `staticPtrKeys`? Why? How would you use it? I'm a bit stumped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:26:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:26:00 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.fe3d8dd9175e3d3815f16357dcf71be3@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3870 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:26:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:26:06 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.10e50da6851d73e669192d69ae75f6e2@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:26:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:26:57 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.39d49ffc1bae8fe927b61364b66cab83@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I suggest adding a strict variant of the iterate function to the > Data.List module, as others seem to have had a need for it too. It is > useful when you want to repeatedly apply a function a large number of > times and get the final result. Using the standard iterate function in > this way results in the whole list being held in memory, as exemplified > in the following GHCi session (code compiled with -O2 behaves similarly): > > > let f = (+1) in iterate f 0 !! 10000000 > *** Exception: stack overflow > > Using a strict variant of iterate seems to be sufficient for this code to > run in O(1) memory: > > > let iterate' f x = x `seq` x : iterate' f (f x) > > let f = (+1) in iterate' f 0 !! 10000000 > 10000000 > > I have no idea if this is something that could/should be detected by the > strictness analyzer; that would obviously be preferable if it is indeed > possible. New description: I suggest adding a strict variant of the iterate function to the Data.List module, as others seem to have had a need for it too. It is useful when you want to repeatedly apply a function a large number of times and get the final result. Using the standard iterate function in this way results in the whole list being held in memory, as exemplified in the following GHCi session (code compiled with -O2 behaves similarly): {{{ > let f = (+1) in iterate f 0 !! 10000000 *** Exception: stack overflow }}} Using a strict variant of iterate seems to be sufficient for this code to run in O(1) memory: {{{ > let iterate' f x = x `seq` x : iterate' f (f x) > let f = (+1) in iterate' f 0 !! 10000000 10000000 }}} I have no idea if this is something that could/should be detected by the strictness analyzer; that would obviously be preferable if it is indeed possible. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:35:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:35:42 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.acc56c56a0190015d0869d7f88b7a1a6@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's not clear what we can/should do about this. I suspect we should just give up on checking types in `StgLint` and just check for compatible kinds (e.g. `TYPE Unlifted` and `Type Lifted` is dodgy; `TYPE Float` and `TYPE Lifted` is definitely wrong). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:39:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:39:45 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.5772c03ec236167a0724daa660649336@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not convinced. You are proposing a counterpart to `Type`. But there is no counterpart to `Expr` in Core. Indeed, in RULEs the patterns are indeed `Expr`s. And casts in terms can indeed mess things up a bit; see `Rules.match`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:45:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:45:26 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.12fa9dcfbdcfe1d03ab5b9bd43cb8d3e@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by gbaz): We're running into this bug in preparing the win32 distro of the Haskell Platform as well, so I'm quite worried about this. For example, ghc-pkg exe seems to break in the same way. In fact I'm not even so sure about doing a win32 release at all for this version of ghc. Advice on if there's a workaround or we should anticipate an emergency patch (or just omit the win32 build of the platform for this reason) would be much appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 14:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 14:45:31 -0000 Subject: [GHC] #12874: Read/Show Incompatibility in base In-Reply-To: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> References: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> Message-ID: <064.a96b231e33e16fd3d2beb9f4ab335258@haskell.org> #12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): Phab:D3871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3871 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 15:09:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 15:09:21 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.b10048517ea0d5c57d763d7e62dfe608@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #13910 may be another manifestation of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 15:25:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 15:25:59 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.b6c0557741c45d3ad5f7393becc99211@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I often find myself working in `Check` and `Match`, and I'd certainly like to address some of these pattern match coverage check-oriented tickets some day. But I often find myself handicapped by my unfamiliarity with the structure of the code in that part of GHC, so I think that in order to productively maintain it, I'd need someone to give a tour of that section of the codebase, highlighting what each thing does. (I've read "GADTs meet their match", but that doesn't really come with a field guide as to how each concept translates to actual GHC code.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 15:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 15:56:59 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.4ef505dd4786462305bc3cade66d78e7@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm struggling to grok this ticket, especially: '''what is the problem we are trying to solve?'''. I'm also concerned about making things too complicated. ''jscholl in comment:74 sounds right on target to me''. Here's my thinking, written out. Let's see if we agree at least about the "Goals" and "Core" part. == Goals == I believe that one goal is * '''The ability to put a block of binary data in the program code, without heavy encoding.''' Is that a goal? Can we focus solely on that for a while? == Core == To meet that goal, in Core, we need * A primitive data type `B#` whose values are simply blobs of binary data. * Some operations over this type; e.g. `lenB :: B# -> Int`, or `unpackString :: B# -> [Char]` or whatever. * Literal values (in Core) for `B#` values. `B#` plays the role of the `(# Int#, Addr# #)` representation mentioned above (comment:38 ff), but without being so concrete. I'm only using "`B#`" as a placeholder; we need a proper name for it! So what is it, precisely? * `B#` could be a completely new primitive type. * Or `B#` could be `ByteArray#`. That would have the major advantage of not adding a new type, and for sure we'd need to be able to turn it into a `ByteArray#`. So I like that, and it's what jscholl suggests in comment:74. * But `B#` can't be `Addr#` (which is a memory address)! Also look at #11312, which is highly relevant because it has the same conclusion. In #11312, I call this new type `String#`, but that's too character-oriented. I think we should focus on binary data. But adopting `B#` would fix the ghastly problems in #11312. == Haskell == If we had this new primitive type, we'd soon want literals for it in Haskell source code. * I suppose we could have a new literal syntax (about whose details I am intensely relaxed). After all, the literals of a language should be expressible I suppose. * But we could say you could only get it via a TH quasiquote e.g. `[bytes| fec923ac |]`? Is that so terrible? Note that everything in comment:84 belongs in this section. By the time we get to Core all this typeclass stuff has gone away. == Other goals == I don't have clarity on how `bytestring` would want to convert a `ByteArray#` to a `ByteString`. That ought to be a constant time operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 16:35:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 16:35:50 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.f6a2d2dfacc25b6cc90772bc83d55b2b@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think it'd be possible to improve this. At the moment we actually ''suppress'' the class error because of the type-equality error. But with a little re-ordering in `TcErrors.reportWanteds` we could fix that. Then we'd at least report both. Suppressing the equality error because it involves an associated type would be significantly harder. But at least you'd get both. Specifically the code in `TcErrors` is this {{{ report1 = [ ("custom_error", is_user_type_error,True, mkUserTypeErrorReporter) , given_eq_spec , ("insoluble2", utterly_wrong, True, mkGroupReporter mkEqErr) , ("skolem eq1", very_wrong, True, mkSkolReporter) , ("skolem eq2", skolem_eq, True, mkSkolReporter) , ("non-tv eq", non_tv_eq, True, mkSkolReporter) , ("Out of scope", is_out_of_scope, True, mkHoleReporter) , ("Holes", is_hole, False, mkHoleReporter) -- The only remaining equalities are alpha ~ ty, -- where alpha is untouchable; and representational equalities -- Prefer homogeneous equalities over hetero, because the -- former might be holding up the latter. -- See Note [Equalities with incompatible kinds] in TcCanonical , ("Homo eqs", is_homo_equality, True, mkGroupReporter mkEqErr) , ("Other eqs", is_equality, False, mkGroupReporter mkEqErr) ] -- report2: we suppress these if there are insolubles elsewhere in the tree report2 = [ ("Implicit params", is_ip, False, mkGroupReporter mkIPErr) , ("Irreds", is_irred, False, mkGroupReporter mkIrredErr) , ("Dicts", is_dict, False, mkGroupReporter mkDictErr) ] }}} I think that moving the "non-tv-eq" line from `report1` into `report2` would do the job. (And maybe change that True to False.) The "Homo eqs" and "Other eqs" could move too. I'm swamped right now, and this would make lots of error messages in `validate` change slightly, each of which needs a check and accept. But maybe someone else can have a go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 17:26:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 17:26:37 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.8de7b2c46ea5bdbfadf8ef487c14286a@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > I'm struggling to grok this ticket, especially: what is the problem we are trying to solve?. I'm also concerned about making things too complicated. > The ability to put a block of binary data in the program code, without heavy encoding. My understanding of this problem is that we want a way to tell ghc ''how'' to compile literals. The ''compiler's'' interpretation of `"..."`, `"..."#`, `[...]` are currently fixed , and we have to do runtime conversion in order to get the interpretation ''we want''. The difference between compiler's and user's interpretation may be address vs heap object, or utf8 vs modified utf8 vs utf16, these difference will decide how codegen emit literal code. So we have to find a way to tell compiler what kind of interpretation we want, it can be via syntax, e.g. we create different syntax for different interpretation. Or we can use some type magic, e.g. the one i suggest. I believe each solution has its own pro and cons. In short words, i believe this is a problem `OverloadedString/OverloadedList` are intended to solve, but solved it wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 17:48:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 17:48:49 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.23ae2a668250f7e5d3d576e35f78a949@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): When we moved {{{inline-java}}} to use a ghc plugin, we stopped using the static pointer table. But it would have broken because of this. {{{inline-java}}} was using the static pointer table to store java bytecode. At runtime, the SPT was traversed looking for the bytecode to pass it to the JVM. The bytecode was inserted in the SPT by creating some static forms which were never accessed other than through the SPT traversal. But as I said, inline-java doesn't use the SPT anymore. Maybe mnislaih has another use case. The documentation for {{{staticPtrKeys}}} is available in the module {{{GHC.StaticPtr}}}. https://www.stackage.org/haddock/lts-9.0/base-4.9.1.0/GHC-StaticPtr.html We could say more in the user guide, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 18:48:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 18:48:03 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.d31db6fd191470056a46d5c7b4973fcd@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): I maintain the {{{clr-inline}}} package, which follows in the footsteps of {{{inline-java}}} for the .Net platform and is indeed broken by this change. The static pointer table is used to register bytecode objects, which are then loaded lazily at initialisation time. Since {{{staticPtrKeys}}} was mentioned in the module haddocks, I assumed it was stable api. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 20:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 20:47:52 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.e8433f632302850fb136ebd6c4ff5c22@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > My understanding of this problem is that we want a way to tell ghc how to compile literals. That's the bit under "Haskell" in comment:86. But we still need to compile them into something. But what? That's the bit under "Core" in comment:86. Once we have the Core bit settled we can return to the Haskell bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 20:53:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 20:53:32 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.df7a4b33d799eef7b7874977a152b140@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > inline-java was using the static pointer table to store java bytecode. Crumbs! It was never designed for that purpose! It's like using a hammer to mow the lawn: a tool for one job used for another. The trouble is that, becuase it wasn't designed for the purpose, it keeps failing to serve that purpose. The danger is that, to keep serving the accidental application, the original concept gets muddied. Let's stand back. If we want to register bytecode objects (I'm terribly hazy about what that even means) what is a general, re-usable mechanism that GHC might provide to make that (and perhaps other things) possible? You say you aren't using the SPT for this purpose any more. What are you using? Does it nicely serve the purpose? Could mnislaih use it too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 23:37:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 23:37:51 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.25fc2661c48393579d98bac73d761d94@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So if I use isJoinId, won’t this delay the effect of the patch to the first run off the occurrence analyser after a simplifier run True. And in fact `willBeJoinId` is simpler than I thought, so probably ok. But you'll need to ensure that you pass a occ-anal-tagged binder to `occAnalNonRecRhs`. And that in turn means you need to pass a tagged binder to `occAnalUnfolding` (not currently done) and `occAnalRules` (currently done). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 18 23:47:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Aug 2017 23:47:15 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.db439f7e70bf914d1245a5339bdf04cf@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Also, safe is recursive, so we don’t inline into it anyways. Ah! Here is yet another place where join points are special. Consider {{{ join j = e in joinrec j2 x = ...j... }}} where there is just one occurrence of `j` in `j2`. Normally we'd be leery about inlining `j` under that `\x` because we might lose sharing. But nullary join points aren't thunks, so the situation is just as if we'd said {{{ join j _ = e in joinrec j2 x = ...(j ())... }}} when we'd cerainly inline it (via `preInlineUnconditinoally`). So let's make join points do that. In `preInlineUnconditionally`: {{{ | otherwise = case idOccInfo bndr of IAmDead -> True -- Happens in ((\x.1) v) occ at OneOcc { occ_one_br = True } -> try_once (occ_in_lam occ) (occ_int_cxt occ) _ -> False }}} In the `occ_one_br = True` alternative, add a guard {{{ | isJoinId bndr -> True -- New | otherwise -> try_Once (occ_in_lam occ) ... as before }}} That should be good for everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 00:44:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 00:44:57 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.e8be35314a41d78722ac3430edfe0e34@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): @simonpj That's mostly what I propose in https://ghc.haskell.org/trac/ghc/wiki/StaticData Your `B#` is my `StaticData#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 01:12:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 01:12:04 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.489d57fe75b333a29706531798afeeec@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Finally there are the multiple occurrences of `ds5`. I think that `ds5` counts as `smallEnoughToInline` and hence `postInLineUnconditionally` inlines it in HEAD. But in this variant I'm not longer sure becuase it's outside the recursive loop. Maybe it didn't start that way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 01:13:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 01:13:17 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.f11c6bfa2c766cf5e012de02f0f4a05d@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): @simonpj let say we fixed `B#` to `ByteArray#` , people still want to ask compiler turn literal into `ByteArray#` in different ways, maybe ASCII with overflow warning , maybe standard utf8. The point is we can't fix how compiler compile literal into `B#` or whatever primitive we choose.I fail to see how above "Core" section mention that. And I really don't think the problem laid in a universal `B#` selection: I just the ability to choose between `Addr#` or `ByteArray#' or `(# Int#, Addr# #)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 01:37:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 01:37:22 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.5e9a3778733cd1829b57a201981aa784@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I know of three ways to accomplish it in ghc-8.2.1 without the SPT. 1. Use {{{addForeignFile}}} and {{{addTopDecls}}} to make the bytecode available via a foreign import. https://gist.github.com/facundominguez/82f6768e1f4d5fbfecf008115226a484 2. Use {{{addForeignFile}}} to insert a constructor function in the module to initialize a global bytecode table when the module is loaded. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index- constructor-function-attribute 3. Like (2), but instead of using {{{addForeignFile}}} to insert the constructor function, use a GHC plugin to inject it. This is the approach that inline-java uses in the latest version in the repo. https://github.com/tweag/inline- java/blob/6c4aa0e94a4952ce91a498d2b64198a5e158ee57/src/Language/Java/Inline/Plugin.hs#L73 (3) works with 8.0.2 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 02:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 02:24:01 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.e26f3dbc92c01c058fb6053090d83d67@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It's true that there's no counterpart to `Expr`, but perhaps there could be. The problem is that it wouldn't pay its way: the only real usage for the pattern type would be in RULEs. In types, though, patterns come up more often, perhaps tilting the needle enough. Another way of examining this: pattern-matches in terms are elaborately desugared into nested cases. If they weren't, the case for an expression- level pattern type would be stronger. And in types, we don't do this desugaring. On the other hand, there is my sentiment in comment:1. I don't think I'd argue with "Well, that's a good idea, but not worth it since we'll be doing much heavier refactoring soon, anyway." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 02:32:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 02:32:42 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.ebc452a522e59172db29c3354c0bdc86@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Good sleuthing here. Do you think you can fix the bug? I don't think it would be too hard. My guess is that fixing this in concert with #13985 will work nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 03:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 03:15:42 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.183b3ad54bf0d66cec3e77217c57ec2f@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The muddiness all comes down to this: If GHC knows `m a ~ Maybe Int`, should it choose `m ~ Maybe` and `a ~ Int`? After all, if `m` could be an unsaturated type family, committing to the above decomposition would be wrong. This kind of inference seems unlikely in `:kind` or `:kind!`, though I can't rule it out if someone tried to. In the end, I think we should just keep the current behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 03:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 03:28:30 -0000 Subject: [GHC] #13636: Enable -Wcpp-undef In-Reply-To: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> References: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> Message-ID: <061.beaa60a94d81d78a255d0a779d44b093@haskell.org> #13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6267d8c9e54663a23f0ac13556522a53580d0910/ghc" 6267d8c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6267d8c9e54663a23f0ac13556522a53580d0910" Enable -Wcpp-undef for GHC and runtime system This gets us much of the benefit of enabling it globally, which avoiding (at least for now) the pain of making the core libraries build as well. See #13636. Test Plan: Validate Reviewers: erikd, austin Subscribers: rwbarton, thomie GHC Trac Issues: #13636 Differential Revision: https://phabricator.haskell.org/D3517 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 03:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 03:28:30 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.53cf5db0a899498465e7264386008ad8@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8e5b6ec6566da57d15b0810a07902d9eac85cb79/ghc" 8e5b6ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e5b6ec6566da57d15b0810a07902d9eac85cb79" Add strict variant of iterate This closes the nearly-eight-year-old #3474. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 03:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 03:28:30 -0000 Subject: [GHC] #12155: Description of flags cut off In-Reply-To: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> References: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> Message-ID: <060.5dacb004158e13e8aae76c60280848a3@haskell.org> #12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: (none) Type: task | Status: patch Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: flags Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #11654 | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cf8ab1ced6f15dad03dd7bcc454ef759cf4d3b3d/ghc" cf8ab1ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf8ab1ced6f15dad03dd7bcc454ef759cf4d3b3d" users_guide: Convert mkUserGuidePart generation to a Sphinx extension This removes all dependencies the users guide had on `mkUserGuidePart`. The generation of the flag reference table and the various pieces of the man page is now entirely contained within the Spinx extension `flags.py`. You can see the man page generation on the orphan page https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghc.html The extension works by collecting all of the meta-data attached to the `ghc-flag` directives and then formatting and displaying it at `flag-print` directives. There is a single printing directive that can be customized with two options, what format to display (table, list, or block of flags) and an optional category to limit the output to (verbosity, warnings, codegen, etc.). New display formats can be added by creating a function `generate_flag_xxx` (where `xxx` is a description of the format) which takes a list of flags and a category and returns a new `xxx`. Then just add a reference in the dispatch table `handlers`. That display can now be run by passing `:type: xxx` to the `flag-print` directive. `flags.py` contains two maps of settings that can be adjusted. The first is a canonical list of flag categories, and the second sets default categories for files. The only functionality that Sphinx could not replace was the `what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx cannot do. As the flag is deprecated, I added the list as a static file which can be updated manually. Additionally, this patch updates every single documented flag with the data from `mkUserGuidePart` to generate the reference table. Fixes #11654 and, incidentally, #12155. Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11654, #12155 Differential Revision: https://phabricator.haskell.org/D3839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 03:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 03:28:30 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.e7b9815ef9e4621594565be09639ca8f@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | 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): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cf8ab1ced6f15dad03dd7bcc454ef759cf4d3b3d/ghc" cf8ab1ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf8ab1ced6f15dad03dd7bcc454ef759cf4d3b3d" users_guide: Convert mkUserGuidePart generation to a Sphinx extension This removes all dependencies the users guide had on `mkUserGuidePart`. The generation of the flag reference table and the various pieces of the man page is now entirely contained within the Spinx extension `flags.py`. You can see the man page generation on the orphan page https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghc.html The extension works by collecting all of the meta-data attached to the `ghc-flag` directives and then formatting and displaying it at `flag-print` directives. There is a single printing directive that can be customized with two options, what format to display (table, list, or block of flags) and an optional category to limit the output to (verbosity, warnings, codegen, etc.). New display formats can be added by creating a function `generate_flag_xxx` (where `xxx` is a description of the format) which takes a list of flags and a category and returns a new `xxx`. Then just add a reference in the dispatch table `handlers`. That display can now be run by passing `:type: xxx` to the `flag-print` directive. `flags.py` contains two maps of settings that can be adjusted. The first is a canonical list of flag categories, and the second sets default categories for files. The only functionality that Sphinx could not replace was the `what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx cannot do. As the flag is deprecated, I added the list as a static file which can be updated manually. Additionally, this patch updates every single documented flag with the data from `mkUserGuidePart` to generate the reference table. Fixes #11654 and, incidentally, #12155. Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11654, #12155 Differential Revision: https://phabricator.haskell.org/D3839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 07:31:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 07:31:57 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.34c75496996a78b7ab27a2e2a51ce526@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"ee2e9ece388e75ac433097ac726a555a07ae0830/ghc" ee2e9ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee2e9ece388e75ac433097ac726a555a07ae0830" Correct incorrect free in PE linker Summary: The big-obj support (D3523) had introduced an early free on the info structure. Because the pointer is not NULL'd and the default of all the utility functions was to the standard object format, it all kept working. The one big-obj test that exists was subjected to a timing issue. usually the test ran quickly enough that the allocator hasn't had time to reclaim the memory yet, so it still passed. This corrects it. Also as it so happens, static LLVM libraries from mingw-w64 are compiled using big-obj. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13815, #13093 Differential Revision: https://phabricator.haskell.org/D3862 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 07:31:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 07:31:57 -0000 Subject: [GHC] #13815: Support Windows big-obj format In-Reply-To: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> References: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> Message-ID: <059.bb4cf7a4a44229527fd50d0cfd0c760b@haskell.org> #13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3523 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"ee2e9ece388e75ac433097ac726a555a07ae0830/ghc" ee2e9ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee2e9ece388e75ac433097ac726a555a07ae0830" Correct incorrect free in PE linker Summary: The big-obj support (D3523) had introduced an early free on the info structure. Because the pointer is not NULL'd and the default of all the utility functions was to the standard object format, it all kept working. The one big-obj test that exists was subjected to a timing issue. usually the test ran quickly enough that the allocator hasn't had time to reclaim the memory yet, so it still passed. This corrects it. Also as it so happens, static LLVM libraries from mingw-w64 are compiled using big-obj. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13815, #13093 Differential Revision: https://phabricator.haskell.org/D3862 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 07:44:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 07:44:04 -0000 Subject: [GHC] #14138: Friend modules Message-ID: <051.130fa7ba7f3b47c6ede609d4529f2e6a@haskell.org> #14138: Friend modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- For the sake of testing, I would like to import everything from a module that I test, not only the things it exports. {{{#!hs friend import A -- everything from A friend import B (notExported) -- notExported from B friend import qualified C.D as E -- you guess it ... }}} Current work arounds: * Give up on export lists (ruins haddockumentation) * Extra levels of indirection, see https://mail.haskell.org/pipermail/beginners/2010-November/005717.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 10:55:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 10:55:23 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.4b460bf60b818600aabc263baa8e8b8a@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Maybe it didn't start that way? Quite possible (didn’t check). The problem of things floating out of recursive lets and never back in has beein bothering me for a while, especially in the context of https://ghc.haskell.org/trac/ghc/ticket/10918#comment:5. Maybe the following thought deserves a ticket of its own: Currently, we cannot inline `x` in {{{ let x = f x0 in let go 10 y = exit1 x y go 20 y = exit2 (y*y) go 30 y = exit3 0 go i = go (i+1) (y*2) in go y }}} because it goes into a recursive function and under lambdas, and that is, in general, dangerous. But in this case, it would be ok because the occurence of `x` is not actually on a recursive path. But that is hard to spot in this form! It would be easy to spot if we take all codepaths of `go` that do not mention `go` and float them out of the recursive let ''as non-recursive jointpoints'': {{{ let x = f x0 in join j1 y = exit1 x y join j2 y = exit2 (y*y) join j3 = exit3 0 let go 10 y = call j1 y go 20 y = call j2 y go 30 y = call j3 go i = go (i+1) (y*2) in go y }}} and now the existing machinery will happily inline `x` into `j1` or `j2`. In the example of this ticket, we’d move all occurrences of `ds5` out of `save` this way, and the inliner could do its work unhindered by the recursion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 11:05:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 11:05:18 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.a48fb69f1dc6573eb3c276d819a8193d@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Now lvl6 will be inlined at its single call site. Indeed the change to `preInlineUnconditionally` has the prognosed effect. I passed it to `perf.haskell.org` for performance evaluation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 12:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 12:48:14 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.cfcf971250cd9dee32468d88a1633dab@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: Replying to [comment:5 goldfire]: > The muddiness all comes down to this: If GHC knows `m a ~ Maybe Int`, should it choose `m ~ Maybe` and `a ~ Int`? After all, if `m` could be an unsaturated type family, committing to the above decomposition would be wrong. > > This kind of inference seems unlikely in `:kind` or `:kind!`, though I can't rule it out if someone tried to. Thanks for explaining this. > In the end, I think we should just keep the current behavior. That sounds reasonable to me. Given that there's already a section in the users' manual about this, I'd say we can just close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 13:31:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 13:31:15 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.187a9f5b02f2069a06af0542bd440de3@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Also note that floating out the exit code paths from recursive join points greatly improves the effectivity of the demand analyser, possibly to the point of making Call Arity obsolete (at least in some common cases). Consider this code: {{{ let t = f a -- a thunk in let go 0 y = t y + 5 go n y = go (n-1) (y*y) in case go 100 2 of … }}} The cardinality analysis is not able to eta-expand `t` because it has to assume it is used multiple times. Call Arity, with the rather complicate co-call graph analysis finds that `t` is called at most once and allows for its eta-expansion. But let’s see what happens if we apply some of the ideas from this tickets and from #14068. First we apply #14068: {{{ let t = f a -- a thunk in let go n y = joinrec j 0 y = t y + 5 j n y = call j (n-1) (y*y) in call j n y in case go 100 2 of … }}} I’d like to call this ''first joinrec normal form'', defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”. Next we apply the idea above of floating out all expressions not mentioning the join point {{{ let t = f a -- a thunk in let go n y = join jexit y = t y + 5 joinrec j 0 y = call jexit y j n y = call j (n-1) (y*y) in call j n y in case go 100 2 of … }}} I’d like to call this ''second joinrec normal form'', defined as “first joinrec normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are invocations a join point”. This form minimizes the amount of code that is inside the `joinrec`, which is good, as many parts of the compiler (simplifier, demand analyzer) have to make conservative assumptions with recursion. Now the normal demand analyser can infer that the non-recursive `go` is called at most once, hence the join-point `jexit` is called at most once (by virtue of being a join-point, it can do so without looking at its use- site, which are inside a recursive group), and hence `t` is used at most once. Success! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 13:44:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 13:44:09 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.c2bb223bb4bded7d4ea9d80e52268ac9@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:11 nomeata]: > > Now lvl6 will be inlined at its single call site. > > Indeed the change to `preInlineUnconditionally` has the prognosed effect. I passed it to `perf.haskell.org` for performance evaluation. Two changes observed: Runtime of `scs` improved by 3% (could be noise). But compiler performance regressed slightly (around +1% allocations in a few cases). Biggest loser is the parsing compiler performance benchmark `tests/alloc/parsing001`, 3% increase of allocations. I am not inclined to hunt down that regression (I’d require building GHC twice with identical settings and staring at lots of ticky profiles, and then staring at core code), I hope that’s ok. My completely unfounded gut feeling is that a join-point is inlined into a recursive function, and then floated out again in a form that is no longer a join point. Given these results, do you want me to write a Note and push it to master, or not do that just yet and maybe first follow the breadcrumb “we'd like the FloatOut pass not to float out tail-calls from a joinrec”? (But see above why it seems to me that floating out tail-calls from a joinrec is very desirable…) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 14:59:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 14:59:38 -0000 Subject: [GHC] #12155: Description of flags cut off In-Reply-To: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> References: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> Message-ID: <060.79fa34aaef8b7a2979188ac260cce146@haskell.org> #12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: (none) Type: task | Status: closed Priority: low | Milestone: 8.4.1 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: flags Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #11654 | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 15:01:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 15:01:34 -0000 Subject: [GHC] #13636: Enable -Wcpp-undef In-Reply-To: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> References: <046.158ec470c576ad7ea7046a8ce856111c@haskell.org> Message-ID: <061.74afffe5d2822108167d311c108156a2@haskell.org> #13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 15:02:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 15:02:38 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.dc397434c57672e356611e6422abf5e0@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Thanks Patrickdoc! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 15:38:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 15:38:39 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.4a783a1408330a601d04442e122b77fb@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 18:24:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 18:24:40 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.8fa1f5c559908c1cfbd4464753e915b0@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ryan, have you seen [[wiki:PatternMatchCheckImplementation]]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 19 19:16:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Aug 2017 19:16:24 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.57fcac82b8a87155b95b770d8783a492@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I believe that one goal is > > > The ability to put a block of binary data in the program code, without heavy encoding. > > Is that a goal? Can we focus solely on that for a while? That is indeed a goal. Another in my mind equally-important goal is to be able to support constant-time length given the literals we write today. This is important for being able to efficiently implement things like `bytestring` `Builder` in terms of `memcpy`. > Or `B#` could be `ByteArray#`. That would have the major advantage of not adding a new type, and for sure we'd need to be able to turn it into a `ByteArray#`. So I like that, and it's what jscholl suggests in comment:74. One issue with this is that we would gain a word of overhead for each string literal (assuming we use `B#` to implement Haskell's `String`). I took some measurements a while back and found that short strings are quite common, so this may be a hard cost to accept. > I don't have clarity on how bytestring would want to convert a `ByteArray#` to a `ByteString`. That ought to be a constant time operation. I may be missing something but I don't believe this should pose any particular trouble. Afterall, a `ByteString` is essentially a `ForeignPtr` and some length/offset information. `byteArrayContents#` allows us to get the `Addr#` from a (pinned) `ByteArray#`, from which we can construct a `Ptr` and in turn a `ForeignPtr`. Since we are talking about static data `byteArrayContents#` should be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 02:29:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 02:29:31 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313985=3A_GHC_8=2E0_regression=3A_?= =?utf-8?q?=E2=80=98k=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <050.713def54cc371cef366e72c06648a03c@haskell.org> References: <050.713def54cc371cef366e72c06648a03c@haskell.org> Message-ID: <065.71a7f917d1218ee087ec3466e2ef5728@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13738, #14131 | Differential Rev(s): Phab:D3872 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3872 * related: #13738 => #13738, #14131 Comment: Thanks Richard, that `dfid_pats` hint helped me figure out a solution to this as part of the grand Phab:D3872 patch, which also fixes #13988 and #14131. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 02:30:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 02:30:34 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.100d393af6cad9ed5f59b131ed45aa12@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Phab:D3872 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3872 * related: => #13985 Comment: Replying to [comment:5 goldfire]: > Do you think you can fix the bug? You got it! See Phab:D8372, which also fixes #13985 and #13988. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 02:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 02:31:54 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.a5314821b53ff02c320e0ece385e98e8@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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:D3872 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3872 Comment: I ended up needing to fix this as a part of an unrelated patch, Phab:D3872. (Note that I borrowed the solution for this particular issue from Richard, so the credit should go to him.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 02:36:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 02:36:15 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.6c4fb2652b9aa674f65b69c90eeb25c4@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13985 => #7938, #9574, #13985 Comment: It's also worth noting that Phab:D3872 reverses a design decision made in #7938 and #9574 to only allow kind variables in the RHSes of associated type instances if they're explicitly bound by LHS type patterns. But I think this is the right thing to do, because otherwise you can't have things like: {{{#!hs class C k where data family Nat :: k -> k -> Type instance C (k -> Type) where newtype Nat :: (k -> Type) -> (k -> Type) -> Type where Nat :: (forall xx. f xx -> g xx) -> Nat f g }}} And rejecting this feels like the wrong stance to take. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 13:39:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 13:39:29 -0000 Subject: [GHC] #14139: Kind signature Message-ID: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> #14139: Kind signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 don't understand the rules for kind signatures / CUSKs but this works {{{#!hs import Data.Singletons.Prelude data Some (f :: u ~> v) where Some :: Sing (x :: u) -> f @@ x -> Some f }}} but this doesn't? {{{#!hs import Data.Kind import Data.Singletons.Prelude data Some :: (u ~> v) -> Type where Some :: Sing (x :: u) -> f @@ x -> Some f -- • Expected kind ‘u ~> v’, but ‘f’ has kind ‘u ~> *’ -- • In the first argument of ‘Some’, namely ‘f’ -- In the type ‘Some f’ -- In the definition of data constructor ‘Some’ -- | -- 5 | Some :: Sing (x :: u) -> f @@ x -> Some f -- | ^ -- Failed, modules loaded: none. }}} I have to quantify over them for it to work `forall u v. (u ~> v) -> Type`, if this is expected I feel like the error message ought to be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 13:39:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 13:39:58 -0000 Subject: [GHC] #14139: Kind signature not accepted (singletons) (was: Kind signature) In-Reply-To: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> References: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> Message-ID: <066.e69f47b3fbcbaa228d9feb8ffe63da2d@haskell.org> #14139: Kind signature not accepted (singletons) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 14:46:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 14:46:25 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.c77206c54a003d924a0ce194fe25f7c2@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): I still wasn't able to use gdb to any good, but I think I found out the problem. The tl;dr version is: `addDLLHandle` assumes that import table is always present and it is not the case for 32-bit `ntdll.dll`. The long version is: I have stumbled upon some code for reading import table - https://stackoverflow.com/questions/15960437/how-to-read-import-directory- table-in-c#17457077. The GHC currently uses somewhat different but simpler approach. In particular it doesn't use anything resembling `Rva2Offset` function. I tried to use `Rva2Offset` and friends from the post but it didn't work. I didn't manage to debug it, but while trying to I noticed that post's code explicitly checks for the case when dll has no import table. I added this check to ghc and it seems that was enough to get `ghc --interactive` working. The check is: {{{ diff --git i/rts/linker/PEi386.c w/rts/linker/PEi386.c index 42e700805e..011b0a8314 100644 --- i/rts/linker/PEi386.c +++ w/rts/linker/PEi386.c @@ -240,6 +240,13 @@ static void addDLLHandle(pathchar* dll_name, HINSTANCE instance) { (PIMAGE_IMPORT_DESCRIPTOR)((BYTE *)instance + header-> OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress); + bool importTableMissing = + header->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].Size == 0; + + if (importTableMissing) { + return; + } + /* Ignore these compatibility shims. */ const pathchar* ms_dll = WSTR("api-ms-win-"); const int len = wcslen(ms_dll); }}} @Phyx- is the fix sensible? Should we try to merge it in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 14:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 14:48:57 -0000 Subject: [GHC] #14139: Kind signature not accepted (singletons) In-Reply-To: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> References: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> Message-ID: <066.a63f686df7ab69ae0724c51ad11297a0@haskell.org> #14139: Kind signature not accepted (singletons) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13365 Comment: Yep, this is a CUSK issue. [http://git.haskell.org/ghc.git/blob/1cdceb9fa3bc3ad01b2d840caad8e735513e14ed:/docs/users_guide/glasgow_exts.rst#l8524 Here] is the relevant section of the users' guide: {{{ - For a datatype with a top-level ``::`` when :ghc-flag:`-XTypeInType` is in effect: all kind variables introduced after the ``::`` must be explicitly quantified. :: -- -XTypeInType is on data T1 :: k -> * -- No CUSK: `k` is not explicitly quantified data T2 :: forall k. k -> * -- CUSK: `k` is bound explicitly data T3 :: forall (k :: *). k -> * -- still a CUSK Note that the first example would indeed have a CUSK without :ghc-flag:`-XTypeInType`. }}} In your example, `v` is not explicitly quantified in the kind signature of `Some`, which explains why its kind defaults to `*` (and results in the error message you see). Since this asks to improve the error message to warn about CUSK behavior, I'll close this as a duplicate of #13365, which seeks the same goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 14:53:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 14:53:28 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.2d4bb0b72aeceafba0dc84769293160c@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: Can you elaborate? What instances are missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 14:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 14:59:13 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.b6704c138941d42722d333462736fea6@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14139 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 14:59:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 14:59:58 -0000 Subject: [GHC] #14139: Kind signature not accepted (singletons) In-Reply-To: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> References: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> Message-ID: <066.04cfbe0a5f1cea26f952df6032fce92a@haskell.org> #14139: Kind signature not accepted (singletons) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 15:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 15:02:42 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.33019ef1cb8c173987859d331b6b1c82@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm confused - is this GADT behavior, or data family behavior? I can't seem to trigger a similar sort of error with a non-family GADT. For instance, this works fine: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Foo where data M (a :: Bool) data F (a :: k) where MkF :: M a -> F a }}} (Granted, these examples aren't quite equivalent, but this was the most convenient way I could think of to constraint the type parameter to be of kind `Bool` without actually giving it an explicit kind signature.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 16:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 16:33:52 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.27003f43a1a62b662ab99d1a3eea2194@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another amusing workaround is that you can use a wildcard type in place of `k`: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce newtype Wrap f a = Wrap (f a) class C f where c :: f a instance C f => C (Wrap f) where c = coerce @(forall (a :: _). f a) @(forall (a :: _). Wrap f a) c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 16:59:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 16:59:22 -0000 Subject: [GHC] #14139: Kind signature not accepted (singletons) In-Reply-To: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> References: <051.0405cc63f69e9ca4aae2eb6da1e708f8@haskell.org> Message-ID: <066.74ee77cd09e94d6aa3aa4d0bd4e4001d@haskell.org> #14139: Kind signature not accepted (singletons) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thanks!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 17:35:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 17:35:32 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.67ba1707f5ea30788b7c3267a877b30e@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I think I meant the Data Type class -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 17:43:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 17:43:30 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.f9b812bff670f1bc7ec632b9d364631c@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): `Rva2Offset` isn't needed because the code in `initLinker` isn't reading in an image file from disk, but rather the loaded image. So the Windows loader has already resolved any RVAs to final addresses. This is why the code is simpler. I am however confused why this fails for some and not others, I would expect the same behavior. Though the original report is for older kernel versions. Anyway nice catch! It looks sensible to me, If you want credit for the fix please attach a `git am` patch and I'll commit. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 19:11:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 19:11:47 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.49e73655fb486eab9c519aeca5f902e7@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh dear, I think I've been operating under a misconception in trying to debug this issue. I was originally under the impression that when renaming the expression `coerce @(forall (a :: k). f a)`, we would implicitly bind the `k` in the `forall` type (i.e., it would become something like `coerce @(forall k (a :: k). f @k a)`. However, this is decidedly //not// the case --as the [http://git.haskell.org/ghc.git/blob/1cdceb9fa3bc3ad01b2d840caad8e735513e14ed:/compiler/hsSyn/HsExpr.hs#l324 Haddocks] for `HsAppType` reveal, we use `LHsWcType` for representing a visible type argument, precisely because it can have wildcards but //not// implicit quantification. In light of this, I think that the original program should actually give a `"Not in scope: type variable 'k'"` error. But there's a problem: `bindLHsTyVarBndr` //always// attempts to implicitly bind any free kind variables in `forall`'d type variables' kind signatures. As a result, `k` never gets reported as out-of-scope after renaming (which would be the ideal way to catch this). What is the best way to detect this scenario, then? We could add a `Bool` argument to `bindLHsTyVarBndr` that controls whether it attempts to implicitly bind free kind variables or not. But this feels like a heavy approach, since we'd be tweaking the behavior of a very widely used function in renamer (and causing a lot of replumbing) only to account for `LHsWcType`, something which AFAICT is really only used in one particular place: visible type application. But I'm not aware of a more clever way to address this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 19:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 19:18:17 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.130ba20e00d8d23d8dd9f064cd29d104@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, but wait! I think there's a way to avoid having to replumb tons of functions in the renamer--just repurpose `RnTyKiEnv`! We already have a datatype: {{{#!hs data RnTyKiEnv = RTKE { rtke_ctxt :: HsDocContext , rtke_level :: TypeOrKind -- Am I renaming a type or a kind? , rtke_what :: RnTyKiWhat -- And within that what am I renaming? , rtke_nwcs :: NameSet -- These are the in-scope named wildcards } }}} If I understand the spirit of this type, it would be quite reasonable to augment `RTKE` with another filed which indicates whether kind variables in a `forall` type should be implicitly quantified or not. If we adopted this approach, then we'd only have to change a couple of call sites, since many of the functions in the renamer already pass around an `RnTyKiEnv` argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 21:16:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 21:16:44 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.b8b5aa8bbfe8e6b79e7408c7f8027b54@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Phab:D3873 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3873 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 21:20:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 21:20:00 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.0ac62c58eab0d15c4fbabaa8c55ad7a2@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer * status: infoneeded => new Comment: Ah, OK. Thanks for clarifying! I don't think this would be too hard to accomplish, if someone wants to volunteer a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 20 22:16:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Aug 2017 22:16:18 -0000 Subject: [GHC] #14140: Better treatment for dataToTag Message-ID: <046.9a79626424ac111932e061637da60868@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In `libraries/Cabal/Cabal/Distribution/System.hs` I found {{{ eqOS :: OS -> OS -> Bool eqOS (OtherOS s1) (OtherOS s2) = s1 == (s2 :: String) eqOs a b = dataToTag a == dataTag b }}} (actually it's not called `eqOS`; it's the derived equality for `OS`). By the time this gets to Core it looks something like this {{{ eqOS a b = case a of OtherOS s1 -> case b of OtherOS s2 -> eqString s1 s2 _ -> case dataToTag b of 16# -> True r -> False _ -> dataToTag a == dataToTag b }}} The `dataToTag` code has been duplicated; and in the `OtherOS s1` branch GHC can constant-fold the `dataToTag` on `a` to `16#`, the tag of `OtherOS`. But GHC is no so clever for the `dataToTag b`. We know that `b` is not `OtherOS`, so we know its tag is not `16#`, so the innermost case is entirely redundant. But we don't spot that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 04:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 04:01:49 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.4f3c48c1afd8d115bfe3522736ff29d1@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It's GADT data family behavior. :) The problem can really happen only with data/newtype instances. In comment:5, you're actually making a kind- indexed GADT. That program shouldn't be accepted, but is due to #13391. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 08:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 08:00:11 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.28d52156f09bf32a65d4bce49a1f3e23@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14139 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #14139 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 08:14:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 08:14:25 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.b06eb6593b6641e0273a7072d116b709@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by sergv): Great! Please use following patch I'm attaching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 08:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 08:14:37 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.31218d92e2dc505e9b4452087fcbc6fe@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by sergv): * Attachment "0001-Fix-loading-of-dlls-on-32bit-windows.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 08:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 08:53:08 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.76dfc83603cab86e794239788a6919db@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's also worth noting that ​Phab:D3872 reverses a design decision made in #7938 and #9574 to only allow kind variables in the RHSes of associated type instances if they're explicitly bound by LHS type patterns. I don't think it reverses it. We just didn't implement it properly. If we wrote out the kind arguments we'd see {{{ class C k where data family Nat @k :: k -> k -> Type instance C (k -> Type) where newtype Nat @(k -> Type) :: (k -> Type) -> (k -> Type) -> Type where Nat :: forall k (f::k->Type) (g::k->Type). (forall xx. f xx -> g xx) -> Nat @(k->Type) f g }}} So that `k` certainly is bound on the left, in the (invisible) kind pattern. > But really, the a is Maybe a is bound by the often-neglected RHS type pattern. I don't like this language. There is no "RHS type pattern". Rather, there are invisible kind patterns on the LHS. And this matters! Consider {{{ type family T (a :: Type) :: Type type family F :: k type instance T Int = Proxy (F :: k) }}} Now `T` does not have a kind parameter, and that `k` on the RHS of the `type instance` really is unbound. Writing out the kind arguments: {{{ type instance T Int = Proxy @k (F @k) }}} which is manifestly wrong. '''Bottom line''': we can't distinguish the two cases in the renamer. We have to check this in the type checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 09:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 09:38:45 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.eb46bbfe0c44aac5788cdce09180a663@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not happy with Phab:D3872. Currently we have {{{ type HsTyPats pass = HsImplicitBndrs pass [LHsType pass] }}} That sugggests that the implicit binders scope only over the patterns. But as we know, they don't. They scope over the RHS too. And indeed, as this ticket discusses, we may have variables that are implicitly bound in the RHS, but are not even mentioned on the LHS. These `HsTyPats` are used in `DataFamInstDecl` and `TyFamInstEqn` (only). For the latter: Currently we have {{{ type TyFamInstEqn pass = TyFamEqn pass (HsTyPats pass) type TyFamDefltEqn pass = TyFamEqn pass (LHsQTyVars pass) data TyFamEqn pass pats = TyFamEqn { tfe_tycon :: Located (IdP pass) , tfe_pats :: pats , tfe_fixity :: LexicalFixity -- ^ Fixity used in the declaration , tfe_rhs :: LHsType pass } }}} where the implicit binders inside `tfe_pats` weirdly scopes over the `tfe_rhs`. Instead we can have {{{ type TyFamInstEqn pass = HsImplicitBndrs (TyFamEqn pass [HsType pass]) type TyFamDefltEqn pass = HsImplicitBndrs (TyFamEqn pass [LHsTyVarBndr pass]) }}} I have not worked through the details, but it seems right to wrap the implicit binders around everything that they scopes over. I suspect that'll make the code easier too. It's similar for `DataFamInstDecl`. Currently we have: {{{ data DataFamInstDecl pass = DataFamInstDecl { dfid_tycon :: Located (IdP pass) , dfid_pats :: HsTyPats pass , dfid_fixity :: LexicalFixity , dfid_defn :: HsDataDefn pass , dfid_fvs :: PostRn pass NameSet } }}} Instead we could have {{{ type DataFamInstDecl pass -- Implicit bndrs here = HsImplicitBndrs pass (DataFamInstEqn pass) data DataFamInstEqn pass = DataFamInstEqn { dfid_tycon :: Located (IdP pass) , dfid_pats :: [LHsType pass] -- No implicit bndrs , dfid_fixity :: LexicalFixity , dfid_defn :: HsDataDefn pass , dfid_fvs :: PostRn pass NameSet } }}} Bubt that's still a bit strange, because the `dfid_fvs` should really be outside the `HsImplicitBndrs`. (And it is for `TyFamEqn`. So perhaps a better way would be to make `DataFamInstDecl` and `TyFamInstDecl` look a bit more like each other, thus {{{ type DataFamInstDecl pass = FamInstDecl pass (HsDataDefn pass) type TyFamINstDecl pass = FamInstDecl pass (LHsType pass) data FamInstDecl pass rhs = FamInstDecl { fid_eqn :: LFamInstEqn pass rhs , fid_fvs :: PostRn pass NameSet } type LFamInstEqn pass rhs = Located (FamInstEqn pass rhs) type FamInstEqn pass rhs = HsImplicitBndrs (FamEqn pass [LHsType] rhs) data FamEqn pass pats rhs = TyFamEqn { tfe_tycon :: Located (IdP pass) , tfe_pats :: pats , tfe_fixity :: LexicalFixity , tfe_rhs :: rhs } }}} We still need the typechecker test for comment:8. Finally: we need user-manual comments to explain what's accepted and what is rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 09:55:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 09:55:37 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.961dc112dc403ce5a152f740ce08062f@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider {{{ data instance T a [a] where T1 :: Int -> T Bool [Bool] T2 :: Char -> T Bool [Char] -- Wrong T3 :: p -> T p q -- Wrong }}} We want to ensure that the result type of each data constructor is a substitution instance of the `T a [a]` in the head. `T2` isn't, so it's rejected. Ditto `T3` But this ticket points out that the user-written signature for the data constructor has invisible (and hence under-specified) kind arguments. We want those kind arguments to conform to the shape of the head too. One way to do this might be, when kind-checking the type signature for a data constructor, * Instantiate the head shape with fresh unification variables * Unify it with the result type of the data constructor That would force the shapes to match, and would instantiate any kind variables appropriately. I'm not sure what we'd do with the kind coercion that this unification would return; but it smells to me like the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 09:57:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 09:57:39 -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.e50691ae5e26d4bdc20e1703ac2694a8@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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard: I'm eager to fix this, because it'll help clean up the ghastly mess in `Note [Scope-check inferred kinds]`. Quit a few other tickets seems to be messing about in this space too. Any progress? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 10:42:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 10:42:33 -0000 Subject: [GHC] #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint Message-ID: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: GHC accepts (amd64) | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile (as it should) {{{#!hs data D where A :: C => D type family C :: Constraint where C = 'True ~ 'False f :: D -> () f A = () }}} with the error "Couldn't match type 'True with 'False". This code, however, does compile without an issue: {{{#!hs data D where A :: C => D type family C :: Constraint where C = TypeError ('Text "error") f :: D -> () f A = () }}} I feel that this is a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 10:58:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 10:58:07 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.a46115cd800a293eadf551644b48ba9f@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Phab:D3873 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I disagree. The `RnTyiEnv` is pushed in recursively; and `bindLHsTyVarBndrs` is used at every nested forall. But that's '''not''' what we want to kind-variable scoping. We only add implicit kind variable binders at the top level of a type signature `LHsSigWcType`. We should not be adding any implicit kind-variable bindings at nested foralls. So * `bindLHsTyVarBndrs` has no business binding implicit kind variables at all! It should not be given an argument `kvs`. (Indeed that argument is empty when `bindLHsTyVarBndrs` is invoked by nested foralls.) * `bindLHsTyVarBndr` should not be calling `bindImplicitKvs` (as it does now). Those kvs should already be in scope, brought into socpe by `rn_hs_sig_wc_type` or `rnHsSigType`. * Instead, `bindHsQTyVars` should call `rnImplicitBndrs` on the passed-in `kv_bndrs`, just as `rn_hs_sig_wc_type` does. Getting rid of this will simplify `bindLhsTyVarBndrs`. And once we have done this, the `k` will simply be reported as out of scope. Does that make sense? Care to have a go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 11:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 11:01:44 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.a482398c2712ac3b2069b005e9197880@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One issue with this is that we would gain a word of overhead for each string literal These are statically allocated literals. I have a hard time believing that a one-word increase in binary size for each string literal will make a noticeable difference to GHC's binary sizes. If we are agreed, let's do it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 11:04:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 11:04:36 -0000 Subject: [GHC] #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint In-Reply-To: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> References: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> Message-ID: <063.262bd760ff848864a4d007667c4d0fd5@haskell.org> #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | CustomTypeErrors Operating System: Windows | Architecture: x86_64 Type of failure: GHC accepts | (amd64) invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Darwin226): * keywords: => CustomTypeErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 11:07:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 11:07:06 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.d00543181f638f9db2af65b88f8c05cd@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's the ability to choose between Addr# or ByteArray#' or (# Int#, Addr# #), etc. that matters That's a separate issue. It is indeed what `OverloadedStrings` is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with `B#` = `ByteArray#`. Moreover, I think jscholl has a preliminary implementation (comment:74). jscholl: would you like to write up your design as a wiki page? Can you share it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 11:52:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 11:52:26 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.652aea45c42d09289dd4882a6c9761e6@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > That's a separate issue. It is indeed what OverloadedStrings is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with B# = ByteArray#. My intention is to add a way to let user choose which primitive types he/she wants. But if there's a must to fix a primitive type, `ByteArray#` may be better than `Addr#` since it can be cast into `Addr#` not vice- versa(at the cost of extra info-header and length words). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:11:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:11:03 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.a06073216a8a9523e8e577eb89aba1d2@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3843 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. But for now I'm arguing ''not'' to adopt Phab:D3843 because, as I argue in comment:13, it smells to much like piling a sticking plaster on top of a sticking plaster. If there's a need, let's stand back and address it. Meanwhile, * Documenting what we have would be extremely helpful. * Perhaps we should add a note to `staticPtrKeys` to say that it's an experimental/unstable feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:14:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:14:43 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.23279dbe89e1029fb9f269825c6223c4@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think we won't pursue #14119, so this ticket is live again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:14:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:14:47 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.a3c1018bdc27be47d2b5e268c3a9aafc@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) 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, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I don't think I'd argue with "Well, that's a good idea, but not worth it since we'll be doing much heavier refactoring soon, anyway." Yes, I think we have enough else to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:41:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:41:25 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.9fe0ddf49c765eba3c6b19e2ab2ebd0a@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are three threads here (maybe we need separate tickets): * '''The original ticket description''': this remains valid. Did you try it? It may not affect the `queens` example because of the other occurrences of `ds5` which I'd missed; but it's a valid and beneficial change regardless. * '''preInlineUnconditionally for join points''' (comment:7). This ok, but it really should not make much difference in either direction. Unlike most inlining, it doesn't eliminate an allocation; it only eliminates an unconditional jump; and that jump will probably be eliminated in Cmm anyway. Doing the inlining cannot (I think) give rise to any knock-on optimisations. I'm intrigued why `scs` goes faster (comment:13). Was that runtime or allocation? Also in the `parsing001` benchmark, try with `-dshow-passes` to see if there's a change in the volume of generated code. That's wha usually makes compiler perf change. * '''Floating out more join points'''. I'm intrigued by your suggestion in comment:10, but I am not persuaded. * Generally speaking GHC inlines things that are called once, the exact reverse of ANF. Doing is more direct and reduces clutter. * We'd need a way to ''stop'' these used-once join points being inlined. * Core has an operational interpretation, and introducing a join connotes an extra jump. Maybe Cmm will eliminate it, but still. * Join points with parameters pass the parameters according to the calling convention, which we don't need. * Join points with parameters might be strictness analysed, specialised, and worker/wrappered. All stupid for called-once join points. * Lastly, it doesn't solve the problem in general. For example {{{ let ys = expensive in letrec f xs = case xs of [] -> ys (p:ps) -> p : f ps in ... }}} Even after loopification `f` is not a `joinrec`. But, if (and only if!) `f` is called once in `...`, it's safe to inline `ys` in the RHS of `f`. Dually, if it was {{{ letrec f xs = case xs of [] -> expensive (p:ps) -> p : f ps in ... }}} (and `f` was called once "outside") we would not want to float `expensive` out. In short, this business of spotting the exit paths of a recursive loop is an interesting challenge, but it goes beyond join points. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:55:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:55:23 -0000 Subject: [GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types In-Reply-To: <050.87f5b641e82d5f06fa4748e90b74c406@haskell.org> References: <050.87f5b641e82d5f06fa4748e90b74c406@haskell.org> Message-ID: <065.c219ffca97ffa9720f24bd484733191d@haskell.org> #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 mrkgnao): I'd like to work on this. Anything I should know? I'm looking at the `template-haskell` source, and it looks fairly understandable, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 12:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 12:58:30 -0000 Subject: [GHC] #14142: Can't invert -dno-debug-output Message-ID: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> #14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- `mk/flavours/validate.mk` sets {{{ GhcStage2HcOpts = -dno-debug-output }}} and there is no way to undo it. E.g. you can't add {{{ GhcStage2HcOpts += -ddebug-output }}} to your `mk/validate.mk` does not work. We should add `-ddebug-output` to invert it. Easy task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:12:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:12:50 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.ab437d2a6c373a2dc70c5cd70d5f6312@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Do you have any input re comment:6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:24:45 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.4e50b61b6a1ead8a877ba2a7b13e15d0@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott Comment: The refactoring suggested in comment:9 sounds good to me. But perhaps I should first do this refactoring in a separate commit, since doing all of this datatype reshuffling and fixing the bugs in #14131 and #13985 simultaneously might be a touch too much. Replying to [comment:9 simonpj]: > We still need the typechecker test for comment:8. Phab:D3872 has this in the form of the `testsuite/tests/polykinds/T13985.hs` test. > Finally: we need user-manual comments to explain what's accepted and what is rejected. Phab:D3872 has this already. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:28:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:28:55 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.9a4638192b7021fe5ce8f3337497f09f@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * differential: Phab:D3873 => Comment: Thanks for the advice! I'll abandon Phab:D3873 and try again, since the approach you recommend is quite different in spirit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:38:29 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.44e8f41945f2b4acb1c88fe290733611@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific, thank you! I'll gladly review -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:40:15 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.39569880c25e6c5591a5207250c6e350@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > We still need the typechecker test for comment:8. What I mean is: the renaner cannot reject the right set of programs (see comment:8). So the renamer must err on the side of acceptance, and leave the type checker to reject programs where variables appear on the RHS that are not bound on the left. > But perhaps I should first do this refactoring in a separate commit Sounds good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:42:38 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.a029d7022981e23acde0c68bd050a1f8@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:11 simonpj]: > What I mean is: the renaner cannot reject the right set of programs (see comment:8). So the renamer must err on the side of acceptance, and leave the type checker to reject programs where variables appear on the RHS that are not bound on the left. Right, this is exactly what Phab:D3872 is doing at the moment. In particular, it changes `TcTyClsDecls` so that we check for free-floating kind variables (or, as you put it, variables that appear on the RHS that are not bound on the left) when typechecking family instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:53:55 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.bab50a1c8605701692c8349989936d23@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Really? `reportFloatingKvs` seems to report variables mentioned in `typat_tvs`, which doesn't look like the ones on the RHS. I wasn't expecting a test in `tcFamTyPats`, but rather in `tcTyFamInstEqn`. DO you have a test like the example in comment:8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:56:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:56:54 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.7dc0168d156e13b60135dc6c7a230bbc@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:6 says: > The problem is that the App instance for (:~>) gets type-checked with a coercion in its patterns Can you boil this out into a simple case? I'm lost. > Have TcHsType proceed normally, but rip the coercions out after-the- fact. That's what happens in Rules. See `DsBinds.decomposeRuleLhs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 13:59:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 13:59:24 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.c0280c3af52632dce23d368fd8c264d6@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > These are statically allocated literals. I have a hard time believing that a one-word increase in binary size for each string literal will make a noticeable difference to GHC's binary sizes. Okay, I ran a quick experiment, compiling GHC with `-ddump-simpl` and grepping for primitive strings in the result. The result is merely ~30000 string literals. As I said earlier, a good fraction of these are short, so the relative change in space needed by string literals is rather large. However, compared to the rest of the program, it's quite small: each literal blowing up by a word would be around 250kB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 14:03:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 14:03:10 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.0d51c66432fcfac427f24c1555293182@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:13 simonpj]: > Really? `reportFloatingKvs` seems to report variables mentioned in `typat_tvs`, which doesn't look like the ones on the RHS. I wasn't expecting a test in `tcFamTyPats`, but rather in `tcTyFamInstEqn`. Ah, I think I managed to confuse you by naming that variable `typat_tvs`. Those are the type variables that are used in type patterns (visible and invisible) //or// the RHS (these are collected during renaming, see `rnFamInstDecl`). We discover in `tcFamTyPats` which variables are actually bound by type patterns, so if there are any used variables that aren't bound, then they're free-floating (and summarily rejected). I suppose I should rename `typat_tvs` to something like `fam_used_tvs` to avoid this confusion. > DO you have a test like the example in comment:8? Yes, see `testsuite/tests/polykinds/T13985.hs`. In the particular case of type family instances, it tests this: {{{#!hs type instance T = Proxy (Nothing :: Maybe a) }}} Which is rejected for having a free-floating `a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 14:07:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 14:07:49 -0000 Subject: [GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types In-Reply-To: <050.87f5b641e82d5f06fa4748e90b74c406@haskell.org> References: <050.87f5b641e82d5f06fa4748e90b74c406@haskell.org> Message-ID: <065.022687341e7c18b4c9b3e69b052d20f9@haskell.org> #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mrkgnao Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => mrkgnao Comment: Thanks, mrkgnao! You're on the right track by looking at the `template- haskell` source code. In particular, I think `showName'` is what needs to change, since that's what is responsible for printing out qualified `Name`s. It might be a simple matter of checking if a `Name` is in a set of special names (like `[]`, `(,)`, etc.) and printing it out unqualified if there's a match. If you have any other questions, feel free to ask on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 14:17:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 14:17:35 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.fefcdbcb1667bf72f2ef3c23588f40dc@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Another use-case I just stumbled across is the coercion of unboxed tuple types: {{{ coerceTuple :: (# a, (# b, c #) #) -> (# a, b, c #) coerceTuple = coerce }}} This does not currently work, but it would be nice if it did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 14:28:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 14:28:04 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.363a568ae743f21fb3a797a42a1ffd92@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The ability to write `coerceTuple` is an entirely separate matter, IIUC. You're asking for the `Coercible` solver to have extra knowledge about unboxed tuple representations that it's currently not privy to. With levity polymorphic `coerce` you could go from `(# Int #)` to `(# Age #)`, where `Age` is a newtype around `Int`. But you'd need some extra juice to go from `(# Int #)` to, say, `(# Int, (##) #)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 14:34:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 14:34:23 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.5a381eaca68ebe502e306520eebb5914@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Currently we use Harbormaster to build Differentials and commits. While > this works, it leaves much to be desired, > > * job scheduling is (literally) random: this means that some patch > authors end up waiting literally ways for their patches to be built > * there is little support for automatic provisioning of builders: this > means we can't scale to meet demand and make poor use of our > computational resources > * periodic builds (e.g. nightlies) are not supported. > * it lacks a sensible interface for integration with external tools: > this means that efforts like CI-before-merge have been pushed off > * status reporting is poor: even answering the question of what a given > builder is currently working on is surprisingly difficult > * common maintenance tasks are byzantine: Adding a new builder requires > adding at least six different objects (a Harbormaster Build Plan, a > Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac > Device, and an Almanac Binding) in various Phabricator applications. None > of this configuration can be tracked under version control nor can most > of it be cloned from an existing builder's configuration. > * Design assumptions don't match GHC's constraints: Harbormaster was > designed under the assumption that builds are cheap and computation > plentiful. The maintainers have stated that they have little interest in > supporting environments where this doesn't hold. > > Jenkins, while far from perfect, seems a bit better suited to our needs, > more mature, and far more flexible. This ticket will serve as the > checklist for our move to Jenkins. > > In the end we want, > > * Builders (static or dynamically-provisioned, as appropriate) for > * x86-64, i386 Linux > * x86-64, i386 Windows > * x86-64 Darwin > * x86-64 OpenBSD > * Cross compile from x86-64 to ARM > * Native ARM > > * Differential builds with sensible scheduling (e.g. first build on > 64-bit Linux where machines are cheap, then build on the others) > * Per-commit builds on all > * Nightly builds on all, including > * Collection of binary distribution for user download > * Update of `master` documentation mirror on downloads.haskell.org > * Slow validation (including tests requiring Hackage packages) > * nofib run on some platforms? > * Test-before-merge-to-master New description: Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired: * job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built * there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources * periodic builds (e.g. nightlies) are not supported. * it lacks a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off * status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult * common maintenance tasks are byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration. * Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold. Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins. See [https://ghc.haskell.org/trac/ghc/blog/jenkins-ci Ben's blog post (Aug 17)]. In the end we want, * Builders (static or dynamically-provisioned, as appropriate) for * x86-64, i386 Linux * x86-64, i386 Windows * x86-64 Darwin * x86-64 OpenBSD * Cross compile from x86-64 to ARM * Native ARM * Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others) * Per-commit builds on all * Nightly builds on all, including * Collection of binary distribution for user download * Update of `master` documentation mirror on downloads.haskell.org * Slow validation (including tests requiring Hackage packages) * nofib run on some platforms? * Test-before-merge-to-master -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 15:17:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 15:17:24 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.39c68f54fbc877006235775a3853a384@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872 #13985 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ah, I think I managed to confuse you I am indeed terribly confused. I can now just about see what you are doing. * The `hsib_vars` wrapped around the `HsTyPats` includes (via the renamer) the variables mentioned in the RHS. You arrange that `tc_fam_ty_pats` returns them to its caller. * Now in `tcFamTyPats` you can take that set of variables, and subtract from it those bound on the LHS (gotten from the free vars of the typechecked pates). Result is the ones on the RHS but not LHS. Ugh! I bet that all this will look different, and much more perspicous, once we've done the refactoring in comment:9. As you suggest, let's do that first. Yell if you need any help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 16:24:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 16:24:08 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.fc8d1bef08f53d29ec35fd728e4b0e13@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Tamar Christina ): In [changeset:"34bd43d9c24207a1897aaa4ee6cb70592a3f7acc/ghc" 34bd43d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34bd43d9c24207a1897aaa4ee6cb70592a3f7acc" Fix loading of dlls on 32bit windows The point of fix is to handle case when loaded dll loads no other dlls, i.e. it's import table is empty. GHC Trac Issues: #14081 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 16:26:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 16:26:08 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.c1698c8f9e59bba1c4338cbc4a0a574b@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by Phyx-): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 16:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 16:26:41 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.16fcd130a8fa3171a655f1ce30ec8c41@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): @bgamari if there's an 8.2.2 could you please include this one. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 20:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 20:31:54 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.3564f04ebc932d9a4e3ba907aa40283e@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * owner: (none) => duog Comment: I will have a go -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 20:33:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 20:33:56 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.76ece897a5ea55fdb6b9c20cf1fb35b2@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 11307 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 20:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 20:43:34 -0000 Subject: [GHC] #14142: Can't invert -dno-debug-output In-Reply-To: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> References: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> Message-ID: <061.1fd44be55cec8f0029a6b7b59a6b0a40@haskell.org> #14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3876 Comment: Agreed, this has irked me as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 21 21:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Aug 2017 21:40:20 -0000 Subject: [GHC] #14143: forkProcess leaks file descriptors Message-ID: <047.d2c3d80944c6bbfaf23c485371bca092@haskell.org> #14143: forkProcess leaks file descriptors ----------------------------------------+--------------------------- Reporter: danharaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- This is normal behavior as forking a process in POSIX will copy all file descriptors unless they are marked O_CLOEXEC. But in Haskell it's quite difficult to figure out which FDs need to be manually closed. For example, if a `Handle` to a file is opened in the parent process and isn't referenced in the code passed to `forkProcess`, its FD will leak. In order to safely fork, a user has to know about all `Handle`s and other structures that use file descriptors currently active in the program as well as which ones will survive by being referenced in the child process. A simpler problem is wanting to close most FDs (e.g. perhaps excepting std*) when forking. When you don't know where the file descriptors in the current process are coming from but you want them to be closed, a not uncommon approach is to iterate over all file descriptors and close them all. The `process` library does this. This doesn't work for `forkProcess` if a Haskell program is built against the threaded runtime because the IO event manager holds on to file descriptors it uses for control. Attempting to iterate over all FDs carelessly causes the IO manager to die when `-threaded` is used. As far as I understand, all of these FDs are held by the `Control` structure associated with an `EventManager`: [https://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Event.Control.html#Control] . The `base` library does not expose these modules so there is no way to figure out what they are from user code. In one's own application, these issues are tricky but ultimately surmountable as one in principle has the ability to track down every file descriptor being opened. However, when using `forkProcess` in a library, one might need a sledgehammer. For example, in the `hdaemonize` package it is noted that the library can leak file descriptors as there is no way to deal with this issue: [https://hackage.haskell.org/package/hdaemonize-0.5.4/docs/System-Posix- Daemonize.html#v:daemonize] I am writing a library in the same design space as `hdaemonize` that I would like to be able to sensibly handle file descriptors. In general the problem looks intractable (for example because arbitrary C libraries could initialize their own internal FDs), but if I could know which file descriptors are being used by the IO Manager, then I could at least provide for the use case where no FDs should be shared between parent and child. Would it be sensible to expose more of the guts of the IO Manager in `base`? Are there other parts of the RTS that use file descriptors that need to be preserved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 00:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 00:04:45 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.ec5c059417ae2b93aa4f9e62079a03ed@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I too would like this. My goal/motivation would be to use data families to have smart strict unboxed datatypes with uniform syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 02:13:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 02:13:07 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files Message-ID: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.2.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'm making a pass at the documentation in general, and next up on my list is simplifying the building process a bit. I hope to create something like `docs/dist-install` that would collect and hold all of the generated documentation. This would help in writing the docs, as you could verify links, say, from the user's guide to the library documentation. This would also allow installation and distribution to mainly be a `cp`. While looking into this, I ran into some discrepancies between releases. The contents of !https://downloads.haskell.org/~ghc/VERSION/docs for [https://downloads.haskell.org/~ghc/7.10-latest/docs 7.10], [https://downloads.haskell.org/~ghc/8.0-latest/docs 8.0], and [https://downloads.haskell.org/~ghc/latest/docs 8.2] are all different. 8.0 dropped `*.ps` files and `haddock.pdf`. 8.2 now additionally holds a `windows` folder that has a wide array of binaries and documentation. Going back further, the `Cabal` user's guide used to be included. I searched around for a reason that it was dropped and only found a git commit citing the change from `docbook`. But now most sources use `Sphinx`, so we could generate and include them if we so wished. The `Cabal` guide can be found at: * https://www.haskell.org/cabal/users-guide/ (Version 1.24.2) * https://cabal.readthedocs.io/en/latest/ (Versions 2.0 and HEAD) The `Haddock` guide can be found at: * https://www.haskell.org/haddock/doc/html (Version 2.15.0) * https://haskell-haddock.readthedocs.io/en/latest/ (Versions 2.18.0 and HEAD) * https://downloads.haskell.org/~ghc/latest/docs/haddock.html.tar.xz (GHC release version) Unfortunately, the www.haskell.org links are the most prominent when Googled. To bring this back to a point, I would like to clean up the `docs` folder of the distribution. The `windows` folder inside seems like it might be a mistake. Additionally, `Cabal` and `Haddock` have ended up in strange positions, and I think they probably could both use the same solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 02:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 02:34:51 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.a0bf5c8deee0908b4c6084e8db751750@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed with comment:9. I suppose we could concoct that juice, but it's separate from this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 05:35:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 05:35:43 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.3f91506a4f315bbeda14981a32eeb0b1@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): I have a patch for this (https://github.com/google/codeworld/blob/master /ghc-artifacts/ghc-8.0.2-default-main.patch) which is easy to port to HEAD, but it's not clear to me whether it would be accepted without some form of discussion about whether this is the correct behavior. Any thoughts on the matter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 06:27:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 06:27:57 -0000 Subject: [GHC] #14143: forkProcess leaks file descriptors In-Reply-To: <047.d2c3d80944c6bbfaf23c485371bca092@haskell.org> References: <047.d2c3d80944c6bbfaf23c485371bca092@haskell.org> Message-ID: <062.91ae1efb5f920fcd7dcdd081fa22dc0c@haskell.org> #14143: forkProcess leaks file descriptors -------------------------------------+------------------------------------- Reporter: danharaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: POSIX | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): This one seems to be a *nix classic... :-} Basically the same issue has been discussed e.g. here https://sourceware.org/bugzilla/show_bug.cgi?id=10353. Although I'm not a big fan of Ulrich Drepper, I think he is right in this case: You simply can't know which FDs are open for what reason, at least you can't if you use any kind of external library. The GHC RTS is just one kind of such library, and having some hook for it doesn't solve the problem in general. What about (native) libraries you use? Would it be correct to simply close their FDs or not? One can't know. I think the main problem is that the default for open() is wrong: Normally you do not want to pass down FDs to subprocesses, so O_CLOEXEC should be the default IMHO. In the rare case that the application/library wants an FD to stay open, it should say so explicitly. BTW: What about the O_CLOEXEC flag for the FDs behind Haskell's Handles? Is it on or off? Do we really have the right default? I might be oversimplifying some things here, but given the *nix history, this is a hard problem, and I consider any library closing FDs it doesn't own buggy. Just my 2c... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 10:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 10:05:47 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.a76db98c4291facb56a045e65c6e8452@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So can we add a test case and close (Ben)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 11:24:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 11:24:57 -0000 Subject: [GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. Message-ID: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 7.10.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's a common convention among command-line programs that if the documentation describes short options, such as `-c` and `-d` then it should also accept their combination like `-cd`, unless otherwise stated. Alternatively, if this is not supported, then at least a warning abound unknown option "cd" should be displayed. Instead the process silently accepts `-cd`, and produces a colorful chart (-c) but does not sort by variance (ignores d). I'm not sure what version of hp2ps I use, because it seems to ignore `--version` and `-v` and `--help` does not produce version string anywhere. However: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 13:55:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 13:55:52 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.ec701fc86f886df9211555a8e14d0754@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by bgamari): Ahh, excellent. Thanks Phyx! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:05:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:05:18 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.c33c053670b12d3f9076a3cbd061cdc9@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by Phyx-): @sergv Did all the work on this one :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:07:19 -0000 Subject: [GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. In-Reply-To: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> References: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> Message-ID: <060.70ee487e8a4106a915d0bb0da899f17a@haskell.org> #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree; it would be nice if this were the case. Perhaps you could offer a patch? `hp2ps` is a C program and can be found in the GHC tree in `utils/hp2ps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:13:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:13:04 -0000 Subject: [GHC] #14143: forkProcess leaks file descriptors In-Reply-To: <047.d2c3d80944c6bbfaf23c485371bca092@haskell.org> References: <047.d2c3d80944c6bbfaf23c485371bca092@haskell.org> Message-ID: <062.5708ec12f5758e443d4ad1d19fcf6315@haskell.org> #14143: forkProcess leaks file descriptors -------------------------------------+------------------------------------- Reporter: danharaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: POSIX | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree with Sven; `forkProcess` is (sadly) essentially impossible to support robustly. I have tried quite hard to use it in my own projects in the past but ultimately gave up due to similar issues (or rather, even worse: a program with multiple Haskell threads writing to `stdout` may deadlock after fork as a thread has taken the `Handle`'s `MVar` at the time that `forkProcess` killed the holding thread). tl;dr: `forkProcess` is a can of worms which introduces a number of essentially unsolvable problems. Avoid it at all costs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:21:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:21:01 -0000 Subject: [GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. In-Reply-To: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> References: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> Message-ID: <060.64fa46c35ab403d1e23aeff464fef206@haskell.org> #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by qbolec): I'll devote two hours to that and describe the results if it's not enough time to dive it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:24:04 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.62ba8b2c6b5bc1f2eb8ecb8f14920521@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, the documentation preparation infrastructure is a disaster. Here are a few notes that may be of interest, * I use https://github.com/bgamari/ghc-utils/blob/master/rel- eng/upload.sh#L139 to prepare the documentation that is uploaded to `downloads.haskell.org`. * This script uses the `distrib/mkDocs/mkDocs` script in the GHC tree; this script requires both a Windows and Linux bindist tarball, from which it extracts Haddock and user guide documentation * The `windows` folder in the 8.2 downloads folder appears to be a stale artifact from a failed run of the above script; I have deleted it. * Ultimately we want to have binary distributions and documentation snapshots generated by our continuous integration infrastructure. Building something like `docs/dist-install` would make this much easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:30:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:30:47 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.d7b35da947d822e97ff6d9ab8120e05d@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3879 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:35:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:35:11 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.a02a2d5ab7192e2855ac76f45164dc2b@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This sounds like a perfectly reasonable behavior to me. The patch also looks reasonable, although it should reference this ticket. Also a test would be nice. We might also want to mention this departure from the Report in `docs/users-guide/infelicities.rst` (although perhaps not given that `-main-is` is something of a GHC-specific feature). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:43:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:43:59 -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.6fa5de99f9a1beb86733be9c7cd55364@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.4.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 bgamari): Replying to [comment:40 lippling]: > (I'm not exactly sure if this is the right ticket) > > I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2).\\\\ > The compilation runs smooth, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with an stack overflow error. If you can take the time to reduce your program to a couple of shareable modules it would be appreciated if you could open a new ticket with your repro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:56:18 -0000 Subject: [GHC] #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS In-Reply-To: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> References: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> Message-ID: <065.e40570df3fc8ddfb410ec46e98a64e6f@haskell.org> #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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): Phab:D3866 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"a89bb806c58d3e601b37d6f2c4ebec6514fd2776/ghc" a89bb80/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a89bb806c58d3e601b37d6f2c4ebec6514fd2776" Fix #14114 by checking for duplicate vars on pattern synonym RHSes Summary: Because we weren't checking for duplicate variables on the right-hand sides of pattern synonyms, bogus definitions like this one passed the renamer: ```lang=haskell pattern Foo a <- (a,a) ``` Luckily, the fix is simple. Test Plan: make test TEST=T14114 Reviewers: mpickering, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14114 Differential Revision: https://phabricator.haskell.org/D3866 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:56:18 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.1fe97fda42014203814910f1e0ea7ee4@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"79b259ae6a0a0c17568d7d03d82e378ad4c4001a/ghc" 79b259ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79b259ae6a0a0c17568d7d03d82e378ad4c4001a" Fix #13885 by freshening reified GADT constructors' universal tyvars Summary: When reifying GADTs with Template Haskell, the universally quantified type variables were being reused across both the data type head and the constructors' type signatures. This had the annoying effect of causing sets of differently scoped variables to have the same uniques. To avoid this, we now freshen the universal tyvars before reifying the constructors so as to ensure they have distinct uniques. Test Plan: make test TEST=T13885 Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13885 Differential Revision: https://phabricator.haskell.org/D3867 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:56:18 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.25a47608daa7e86c14059ec8e9f086ac@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6982ee99fb97c252c3faf37faae34131fb66f67c/ghc" 6982ee99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6982ee99fb97c252c3faf37faae34131fb66f67c" Fix #14125 by normalizing data family instances more aggressively Summary: Commit 3540d1e1a23926ce0a8a6ae83a36f5f6b2497ccf inadvertently broke the ability for newtype instances to be used as marshallable types in FFI declarations. The reason is a bit silly: an extra check was added for type synonyms with no type families on the RHS in `normalise_tc_app`, but this check would only skip over type families, not //data// families, since the predicate being used was `not . isTypeFamilyCon`. The fix is simple: just use `not . isFamilyCon` instead so that data families are also skipped by this check. Test Plan: make test TEST=T14125 Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14125 Differential Revision: https://phabricator.haskell.org/D3865 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:56:18 -0000 Subject: [GHC] #13902: Misleading function arity mismatch error with TypeApplications In-Reply-To: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> References: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> Message-ID: <065.42cb1448b660cc3c8e26b7ffb34c6d41@haskell.org> #13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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:D3868 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8476097609a2044e965157380aeb5d4882a71248/ghc" 84760976/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8476097609a2044e965157380aeb5d4882a71248" Revise function arity mismatch errors involving TypeApplications Summary: Currently, whenever you apply a function to too many arguments and some of those arguments happen to be visible type applications, the error message that GHC gives is rather confusing. Consider the message you receive when typechecking `id @Int 1 2`: ``` The function `id` is applied to three arguments, but its type `Int -> Int` has only one ``` This is baffling, since the two lines treat the visible type argument `@Int` differently. The top line ("applied to three arguments") includes `@Int`, whereas the bottom line ("has only one") excludes `@Int` from consideration. There are multiple ways one could fix this, which I explain in an addendum to `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change the herald of this error message to include visible type arguments, and to avoid counting them in the "applied to n arguments" part of the error. The end result is that the new error message for `id @Int 1 2` is now: ``` The expression `id @Int` is applied to two arguments, but its type `Int -> Int` has only one ``` Test Plan: make test TEST=T13902 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #13902 Differential Revision: https://phabricator.haskell.org/D3868 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:56:18 -0000 Subject: [GHC] #12874: Read/Show Incompatibility in base In-Reply-To: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> References: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> Message-ID: <064.ab9bcad9197faead50915e4af6cbb477@haskell.org> #12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): Phab:D3871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8fd959998e900dffdb7f752fcd42df7aaedeae6e/ghc" 8fd95999/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fd959998e900dffdb7f752fcd42df7aaedeae6e" Make the Read instance for Proxy (and friends) ignore precedence Summary: The `Read` instance for `Proxy`, as well as a handful of other data types in `base` which only have a single constructor, are doing something skeevy: they're requiring that they be surrounded by parentheses if the parsing precedence is sufficiently high. This means that `"Thing (Proxy)"` would parse, but not `"Thing Proxy"`. But the latter really ought to parse, since there's no need to surround a single constructor with parentheses. Indeed, that's the output of `show (Thing Proxy)`, so the current `Read` instance for `Proxy` violates `read . show = id`. The simple solution is to change `readParen (d > 10)` to `readParen False` in the `Read` instance for `Proxy`. But given that a derived `Read` instance would essentially accomplish the same thing, but with even fewer characters, I've opted to just replace the hand-rolled `Read` instance with a derived one. Test Plan: make test TEST=T12874 Reviewers: ekmett, austin, hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12874 Differential Revision: https://phabricator.haskell.org/D3871 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:57:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:57:26 -0000 Subject: [GHC] #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS In-Reply-To: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> References: <050.10a593ad0c15f6aac071a5cf115e8114@haskell.org> Message-ID: <065.ae84b00c2b93baadcc08bcb818dfb605@haskell.org> #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T14114 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => patsyn/should_fail/T14114 * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:59:01 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.82f74e8481fbb20b7d652fd78e778f20@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | ffi/should_compile/T14125, | ffi/should_compile/T14125a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => ffi/should_compile/T14125, ffi/should_compile/T14125a Comment: Given that this bug broke some existing programs, it would be nice to merge this into 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 14:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 14:59:56 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.703629ef7064c656b17badd9fb04fae8@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T13885 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T13885 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:00:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:00:45 -0000 Subject: [GHC] #12874: Read/Show Incompatibility in base In-Reply-To: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> References: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> Message-ID: <064.59d90e5a5c930b4bebd43834468ca4de@haskell.org> #12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12874 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => libraries/base/tests/T12874 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:02:09 -0000 Subject: [GHC] #13902: Misleading function arity mismatch error with TypeApplications In-Reply-To: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> References: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> Message-ID: <065.68e055f879c9487dd4b192461194f67e@haskell.org> #13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T13902 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T13902 * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:22:00 -0000 Subject: [GHC] #14117: stg-lint fails on unlifted-type join point binding In-Reply-To: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> References: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> Message-ID: <061.11656d1c83a88a92bdededbfb85e3f2f@haskell.org> #14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3857 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9afaebefe5e59c8e9632f381bee14aa84b44c955/ghc" 9afaebe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9afaebefe5e59c8e9632f381bee14aa84b44c955" StgLint: Allow join point bindings of unlifted type As described in `Note [CoreSyn let/app invariant]` this is allowed. Fixes #14117. Test Plan: Build GHC with BuildFlavour=devel2 with -dstg-lint Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14117 Differential Revision: https://phabricator.haskell.org/D3857 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:22:00 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.c9130670c3b665473652a242bb3c1ac0@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Phab:D3815 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4717ce8658f12f425aebd1fc7f7ad8fe04a81df5/ghc" 4717ce86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4717ce8658f12f425aebd1fc7f7ad8fe04a81df5" Fix incorrect retypecheck loop in -j (#14075) The parallel codepath was incorrectly retypechecking the hs-boot ModIface prior to typechecking the hs file, which was inconsistent with the non-parallel case. The non-parallel case gets it right: you don't want to retypecheck the hs-boot file itself (forwarding its declarations to hs) because you need it to be consistently knot-tied with itself when you compare the interfaces. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, simonpj, austin Reviewed By: bgamari Subscribers: duog, rwbarton, thomie GHC Trac Issues: #14075 Differential Revision: https://phabricator.haskell.org/D3815 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:22:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:22:53 -0000 Subject: [GHC] #14117: stg-lint fails on unlifted-type join point binding In-Reply-To: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> References: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> Message-ID: <061.9f62eb6fdff12ebaa9ec243a36803be6@haskell.org> #14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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:D3857 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 15:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 15:24:28 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.c0d55a5daf8778fa07db897ecdb17670@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Phab:D3815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 16:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 16:03:39 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.aac80049c084b9d2d0f05b7a460663e1@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't think you mean > Instantiate the head shape with fresh unification variables I think you meant * Instantiate the return type with fresh unification variables That is, we don't want the unification variables in the head shape (that is, type patterns), but in the data constructor type. Actually, we already do your version of instantiation, in kind checking. See `TcTyClsDecls.kcDataDefn` and `TcTyClsDefls.tc_fam_ty_pats`. But we don't want to do it ''again'' when checking data constructors. If I understand correctly, this instantiate-and-unify would replace the call to `tcMatchTy` in `rejigConRes`. The kind coercion is easy to dispatch: it will always be reflexive, because the kind of a fully-applied tycon is always `Type`. This always-reflexive property doesn't mean the unification is useless, of course, as it will unify metavariables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 16:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 16:27:48 -0000 Subject: [GHC] #14138: Friend modules In-Reply-To: <051.130fa7ba7f3b47c6ede609d4529f2e6a@haskell.org> References: <051.130fa7ba7f3b47c6ede609d4529f2e6a@haskell.org> Message-ID: <066.c3efbdfe719003fea7236d9654a5551e@haskell.org> #14138: Friend modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 goldfire): * status: new => closed * resolution: => invalid Comment: I, too, have wanted this. I encourage you to make a [https://github.com /ghc-proposals/ghc-proposals ghc-proposal] with this idea, as that forum is now the community-agreed-upon mechanism for introducing new features into GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 18:07:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 18:07:03 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.df05292360681303a883c590aa595421@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T13885 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => Comment: As I discovered in https://phabricator.haskell.org/D3867#108979, there's some cases that Phab:D3867 missed. Reopening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 18:11:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 18:11:19 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.1cf487e8ad321d720f153ea3f8975632@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: 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): Just wanted to make sure this was seen by the appropriate people. The unordered-containers package just merged a PR to switch to using `SmallArray#` internally. I would like to still be able to put hashmaps on the compact heap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 18:12:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 18:12:48 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.0fc11684e7f96622740d8859da198e6a@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact 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: ezyang, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 18:23:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 18:23:27 -0000 Subject: [GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. In-Reply-To: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> References: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> Message-ID: <060.2dc65e24c017cb6e425ecf863e09309c@haskell.org> #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by qbolec): I've run out of time, so I didn't figure out how to configure all the tools to make the pull request, and where and how to add tests for this file. But here is the minimal change I believe fixes the problem: {{{ diff --git a/utils/hp2ps/Main.c b/utils/hp2ps/Main.c index a44e41c862..30dbc2992b 100644 --- a/utils/hp2ps/Main.c +++ b/utils/hp2ps/Main.c @@ -81,7 +81,7 @@ int main(int argc, char *argv[]) goto nextarg; case 'd': dflag++; - goto nextarg; + break; case 'i': switch( *(*argv + 1) ) { case '-': @@ -94,16 +94,16 @@ int main(int argc, char *argv[]) goto nextarg; case 'g': gflag++; - goto nextarg; + break; case 'y': yflag++; - goto nextarg; + break; case 'b': bflag++; - goto nextarg; + break; case 's': sflag++; - goto nextarg; + break; case 'm': mflag++; TWENTY = atoi(*argv + 1); @@ -122,7 +122,7 @@ int main(int argc, char *argv[]) goto nextarg; case 'c': cflag++; - goto nextarg; + break; case '?': default: Usage(*argv-1); }}} In particular it seems that the intent of the {{{ while (argc && argv[0][0] == '-') { while (*++*argv) switch(**argv) { }}} loop was to loop through all characters within a single word, and in did this is how it works for "-p" option, but for all the others `goto nextarg;` is used instead `break;` which skips all the other letters. A better solution in my opinion would be to use [https://stackoverflow.com/questions/9642732/parsing-command-line- arguments some library] to parse the options because the current code (and code style) seems quite complicated to me. I had no time to investigate which of these libraries we could use in order to support MSYS2 etc. Nor the time to actually rewrite the code to use such a library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 18:47:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 18:47:45 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.76a12904f6ad614d68d1be1891831cb3@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new * differential: Phab:D3872 => Comment: ...but Phab:D3872 is in limbo for the time being, so I'll set the resolution back to "new" again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 19:20:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 19:20:44 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.0e163c4bb6a29946708e250a31b46a0d@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T13885 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Sorry, I think I was confused (see my comment in https://phabricator.haskell.org/D3867#108984 which clarifies my confusion). There's no bug remaining here, except for insufficient documentation (which I'll address separately). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 21:43:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 21:43:51 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.5c41d5fbf6b4dd958b3aace009397421@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I had a go at this yesterday, but I ran into a problem. There is a comment on report1: {{{ -- report1: ones that should *not* be suppresed by -- an insoluble somewhere else in the tree -- It's crucial that anything that is considered insoluble -- (see TcRnTypes.trulyInsoluble) is caught here, otherwise -- we might suppress its error message, and proceed on past -- type checking to get a Lint error later }}} This means moving `ReporterSpec`s between report1 and report2 doesn't work as is. It would be possible to make it work by adding some complexity to the suppression logic; make `ReporterSpec`s in report2 unable to suppress `ReporterSpec`s in report1. Alternatively, I think I see how to suppress the equality error in favour of the class instance error: The tuples in report1 and report2 are of type `ReporterSpec`: {{{ type Reporter = ReportErrCtxt -> [Ct] -> TcM () type ReporterSpec = ( String -- Name , Ct -> PredTree -> Bool -- Pick these ones , Bool -- True <=> suppress subsequent reporters , Reporter) -- The reporter itself }}} In `tryReporter`, the current list of unsatisfiable constraints is partitioned with the 2nd member of the tuple. The matching constraints are passed to the `Reporter`, and the non-matching constraints are returned for the next iteration of `tryReporter`. I propose to change the definition to: {{{ type Reporter = ReportErrCtxt -> [Ct] -> TcM [Ct] type ReporterSpec = ( String -- Name , Bool -- True <=> suppress subsequent reporters , Reporter) -- The reporter itself }}} Now the partitioning will be done inside the `Reporter`, and we can write something like: {{{ associated_type_eq :: Reporter associated_type_eq ctxt cts = let associated_type_cts = [ (tf_ct, dict_cts) | tf_ct <- cts , EqPred NomEq ty1 _ <- [classifyPredType (ctPred ct)] , (FamilyTyCon{famTcParent = Just cls}, tf_tys) <- ["some function 1" ty1] , let dict_cts = [ ct' | ct' <- cts , ClassPred cls' cls_tys <- [classifyPredType (ctPred ct)] , cls' == cls && tf_tys "some function 2" cls_tys ] ] yeses = [x | (tf_ct, dict_cts) <- associated_type_cts , x <- tf_ct : dict_cts ] noes = filter (`notElem` yeses) cts in do mkGroupReporter mkDictErr ctxt $ concat [dict_cts | (_, dict_cts) <- associated_type_cts] return noes }}} where "some function 1" gives the type constructor and it's arguments, and "some function 2" checks that this associated type comes from this instance. These functions must exist right? Do you know of any other cases that could be improved by this more powerful factoring? This would affect tracing, since currently in `tryReporter` the partitioning is done, and if the predicate matches anything `tryReporter` traces the `Ct`s that matched. With the partitioning inside the `Reporter` this doesn't work anymore. Perhaps the `Reporter` could also return the yeses. Please let me know whether you think this is a good idea, otherwise I will go ahead and do the simpler option of adding some complexity to the suppression logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 22:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 22:01:58 -0000 Subject: [GHC] #14142: Can't invert -dno-debug-output In-Reply-To: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> References: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> Message-ID: <061.f0fdbc06132da8d8ddb03be1d3b692bf@haskell.org> #14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dbaa9a237b6d9771c0e9bde0e50fd2134c2f4dd0/ghc" dbaa9a23/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dbaa9a237b6d9771c0e9bde0e50fd2134c2f4dd0" DynFlags: Add inverse of -dno-debug-output Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14142 Differential Revision: https://phabricator.haskell.org/D3876 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 22:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 22:01:58 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.73d227eacdcbc22b4293f4de3c8d647a@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834, | Differential Rev(s): Phab:D2707 #9007 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3625728a0e3a9b56c2b85ae7ea8bcabdd83ece6a/ghc" 3625728/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3625728a0e3a9b56c2b85ae7ea8bcabdd83ece6a" Add support for producing position-independent executables Previously due to #12759 we disabled PIE support entirely. However, this breaks the user's ability to produce PIEs. Add an explicit flag, -fPIE, allowing the user to build PIEs. Test Plan: Validate Reviewers: rwbarton, austin, simonmar Subscribers: trommler, simonmar, trofi, jrtc27, thomie GHC Trac Issues: #12759, #13702 Differential Revision: https://phabricator.haskell.org/D3589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 22:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 22:01:58 -0000 Subject: [GHC] #13702: GHC can't produce position independent executables In-Reply-To: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> References: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> Message-ID: <061.10a196d635c079b44553d9b140b1c41e@haskell.org> #13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3589 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3625728a0e3a9b56c2b85ae7ea8bcabdd83ece6a/ghc" 3625728/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3625728a0e3a9b56c2b85ae7ea8bcabdd83ece6a" Add support for producing position-independent executables Previously due to #12759 we disabled PIE support entirely. However, this breaks the user's ability to produce PIEs. Add an explicit flag, -fPIE, allowing the user to build PIEs. Test Plan: Validate Reviewers: rwbarton, austin, simonmar Subscribers: trommler, simonmar, trofi, jrtc27, thomie GHC Trac Issues: #12759, #13702 Differential Revision: https://phabricator.haskell.org/D3589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 22:06:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 22:06:25 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.d11778d6bcb14a54ae260467dafd838e@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This means moving ReporterSpecs between report1 and report2 doesn't work as is I don't agree. I believe you can move "non-tv-eqs", "homo-eqs" and "otehr-eqs"; they are not "truly insoluble". Ah: I see that `trulyInsoluble` is a poorly-named predicate. It is only applied to constraints in `wc_insol`, and they are things like `Int ~ Bool`, but NOT things like `a ~ Int` (which are no necessarily insoluble). It'd be much clearer if `trulyInsoluble` really did check for truly- insoluble constraints. Separately I'd been thinking that separating `wc_insol` from `wc_simple` is a waste of effort; it'd be better to combine them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 22:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 22:44:56 -0000 Subject: [GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. In-Reply-To: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> References: <045.e4b6dd0cfd9e561e5ec0bfe93305b2a8@haskell.org> Message-ID: <060.939498047d5b8496ec6cb26a64130707@haskell.org> #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for giving it a shot! I'll try to finish up your patch when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 23:02:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 23:02:29 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.43afe86b3ae3ed29ccd9876c9d327a50@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "T12170a.comp.stderr" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 23:03:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 23:03:38 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.8381064def3563b39be60cbbb551d929@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I tried moving those three `ReporterSpec`s to report2 (keeping their order, just adding them after "Dicts") and T12170a gave a core lint error (attached). I had assumed it was due to the invariant specified in the comment. I am obviously very new to the typechecker; my presumption was that insoluble constraints were ones that we couldn't defer by inserting a coercion, so it would be very bad to suppress those errors. That was my untrained reading of the lint error. However this must be wrong, because surely there's no problem inserting a coercion from Int to Bool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 23:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 23:43:46 -0000 Subject: [GHC] #14146: Can GHC propose kind restrictions? Message-ID: <051.9c4bef303d701cf3cc969a87a4fa4019@haskell.org> #14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This is UX. As my code gets more polykinded I find myself in situations such as these all the more often {{{#!hs instance (Comonad f, Representable f, Comonad g, Representable g) => Comonad (Compose f g) where extract = undefined duplicate = undefined instance ComonadApply (Compose f g) where (<@>) = undefined }}} {{{ /tmp/a.hs:20:10-35: error: • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration • In the instance declaration for ‘ComonadApply (Compose f g)’ | 20 | instance ComonadApply (Compose f g) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. }}} It would help me if GHC looked up a `Comonad (Compose _ _)` instance, compared the kinds {{{#!hs Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> Type) ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> Type) }}} a simple suggestion like this would be helpful {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a kind signature (ComonadApply (Compose (f :: Type -> Type) g)). }}} Even more amazing would be {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a context (Comonad f, Representable f, Comonad g, Representable g) => ComonadApply (Compose f g) }}} Which the compiler could in theory guess, since following GHC's suggestion iteratively you end up with {{{#!hs ComonadApply (Compose (f :: Type -> Type) g) -- ==> add (Comonad f) to the context of the instance declaration Comonad f => ComonadApply (Compose f g) -- ==> add (Comonad g) to the context of the instance declaration (Comonad f, Comonad g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply (Compose f g) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 22 23:44:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Aug 2017 23:44:36 -0000 Subject: [GHC] #14146: Can GHC propose kind restrictions? In-Reply-To: <051.9c4bef303d701cf3cc969a87a4fa4019@haskell.org> References: <051.9c4bef303d701cf3cc969a87a4fa4019@haskell.org> Message-ID: <066.cede62476e74992bb14155c48d41413e@haskell.org> #14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This is UX. As my code gets more polykinded I find myself in situations > such as these all the more often > > {{{#!hs > instance (Comonad f, Representable f, Comonad g, Representable g) => > Comonad (Compose f g) where > extract = undefined > duplicate = undefined > > instance ComonadApply (Compose f g) where > (<@>) = undefined > }}} > > {{{ > /tmp/a.hs:20:10-35: error: > • No instance for (Comonad (Compose f g)) > arising from the superclasses of an instance declaration > • In the instance declaration for ‘ComonadApply (Compose f g)’ > | > 20 | instance ComonadApply (Compose f g) where > | ^^^^^^^^^^^^^^^^^^^^^^^^^^ > Failed, modules loaded: none. > }}} > > It would help me if GHC looked up a `Comonad (Compose _ _)` instance, > compared the kinds > > {{{#!hs > Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> > Type) > ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> > Type) > }}} > > a simple suggestion like this would be helpful > > {{{ > • No instance for (Comonad (Compose f g)) > arising from the superclasses of an instance declaration > Try adding a kind signature (ComonadApply (Compose (f :: Type -> > Type) g)). > }}} > > Even more amazing would be > > {{{ > • No instance for (Comonad (Compose f g)) > arising from the superclasses of an instance declaration > Try adding a context > (Comonad f, Representable f, Comonad g, Representable g) > => ComonadApply (Compose f g) > }}} > > Which the compiler could in theory guess, since following GHC's > suggestion iteratively you end up with > > {{{#!hs > ComonadApply (Compose (f :: Type -> Type) g) > > -- ==> add (Comonad f) to the context of the instance declaration > Comonad f => ComonadApply (Compose f g) > > -- ==> add (Comonad g) to the context of the instance declaration > (Comonad f, Comonad g) => ComonadApply (Compose f g) > > -- ==> add (Representable f) to the context of the instance declaration > (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) > > -- ==> add (Representable f) to the context of the instance declaration > (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply > (Compose f g) > }}} New description: This is UX. As my code gets more polykinded I find myself in situations such as these all the more often {{{#!hs instance (Comonad f, Representable f, Comonad g, Representable g) => Comonad (Compose f g) where extract = undefined duplicate = undefined instance ComonadApply (Compose f g) where (<@>) = undefined }}} {{{ /tmp/a.hs:20:10-35: error: • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration • In the instance declaration for ‘ComonadApply (Compose f g)’ | 20 | instance ComonadApply (Compose f g) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. }}} It would help me if GHC looked up a `Comonad (Compose _ _)` instance, compared the kinds {{{#!hs Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> Type) ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> Type) }}} a simple suggestion like this would be helpful {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a kind signature (ComonadApply (Compose (f :: Type -> Type) g)). }}} Even more amazing would be {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a context (Comonad f, Representable f, Comonad g, Representable g) => ComonadApply (Compose f g) }}} Which the compiler could in theory guess, since following GHC's suggestion iteratively you end up with {{{#!hs ComonadApply (Compose (f :: Type -> Type) g) -- ==> add (Comonad f) to the context of the instance declaration Comonad f => ComonadApply (Compose f g) -- ==> add (Comonad g) to the context of the instance declaration (Comonad f, Comonad g) => ComonadApply (Compose f g) -- ==> add (Representable g) to the context of the instance declaration (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply (Compose f g) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 00:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 00:06:34 -0000 Subject: [GHC] #14147: Confusing error messages with PolyKinds and superclasses Message-ID: <045.2f97dd08027b2520e8f15eafbacd4f3a@haskell.org> #14147: Confusing error messages with PolyKinds and superclasses -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This program compiles fine: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import Data.Typeable newtype Tagged t v = Tagged v deriving Typeable class (Typeable t) => MyClass t where classF :: t -> Int instance Typeable t => MyClass (Tagged t Int) where classF (Tagged n) = n }}} But if I add `PolyKinds` to the `LANGUAGE` pragma I get: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable k) arising from the superclasses of an instance declaration from the context: Typeable t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Which is very confusing since I don't have a `k` variable anywhere. Adding `-fprint-explicit-kinds` is somewhat better: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable * k) arising from the superclasses of an instance declaration from the context: Typeable k t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged k t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But still confusing. It doesn't really point me towards the solution - specifying that the kind of t is `*` explicitly - if I don't already know how the extension works. It's also annoying that turning on an extension causes a type error, but I don't know if that's fixable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 01:34:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 01:34:43 -0000 Subject: [GHC] #14147: Confusing error messages with PolyKinds and superclasses In-Reply-To: <045.2f97dd08027b2520e8f15eafbacd4f3a@haskell.org> References: <045.2f97dd08027b2520e8f15eafbacd4f3a@haskell.org> Message-ID: <060.8fb6ef94379093a2e33806ea19836dbd@haskell.org> #14147: Confusing error messages with PolyKinds and superclasses -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So here is what's going on. Nowadays, every datatype automatically has a `Typeable` instance emitted (so `deriving Typeable` is redundant). A datatype is `Typeable` only if all of its type parameters are also `Typeable`. So //without// `PolyKinds` enabled, the emitted `Typeable` instance for `Tagged` is: {{{#!hs instance (Typeable t, Typeable v) => Typeable (Tagged t v) }}} So far, so good. Now what happens when you turn on `PolyKinds`? By default, `PolyKinds` generalizes the kind of every type variable to the fullest extent it can. Notice that in the definition of `Tagged`: {{{#!hs newtype Tagged t v = Tagged v }}} Here, `v` is used as a field, so its kind must be `*`. But `t` is completely unconstrained, so its kind is generalized to `k`, a kind variable. Now, you claimed that "don't have a `k` variable anywhere". But that's not true—`Tagged` //does// have a `k` parameter, except that it's invisible (as opposed to `t` and `v`, which are visible). If you enable `-fprint- explicit-foralls`, it's much easier to see this in action: {{{ λ> :set -XPolyKinds λ> newtype Tagged t v = Tagged v λ> :set -fprint-explicit-foralls λ> :type +v Tagged Tagged :: forall {k} (t :: k) v. v -> Tagged t v }}} With this in mind, let's revisit the `Typeable` instance for `Tagged`. Recall that a datatype is `Typeable` only if all of its type parameters are also `Typeable`. Therefore, with `PolyKinds` enabled, the emitted `Typeable` instance is: {{{#!hs instance (Typeable k, Typeable t, Typeable v) => Typeable (Tagged (t :: k) v) }}} Hopefully now it will become clear why you experienced that `Could not deduce (Typeable k)` error message: you had written this instance: {{{#!hs instance Typeable t => MyClass (Tagged t Int) }}} Because `Typeable` is a superclass of `MyClass`, there needs to be a `Typeable (Tagged (t :: k) Int)` instance in scope for this to typecheck. But the only constraint on this instance is `Typeable t`—we don't know that `k` is also `Typeable`! Therefore, fixing this is a matter of adding an extra constraint: {{{#!hs instance (Typeable k, Typeable t) => MyClass (Tagged (t :: k) Int) }}} (This requires the `TypeInType` language extension, which is essentially a beefed up version of `PolyKinds`.) So to recap, I'd argue that there's no bug here, just a tricky interaction between the `Typeable` solver and language extensions. Enabling `PolyKinds` (and thus generalizing kinds) is certainly not guaranteed to keep your existing code compiling! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 03:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 03:10:12 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.cba625021e0980ea5ec86810d968dced@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D3872 => Phab:D3872, Phab:D3881 Comment: I took a go at the suggested refactoring in comment:9 at Phab:D3881. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 09:18:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 09:18:44 -0000 Subject: [GHC] #14148: initTc: unsolved constraints Message-ID: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> #14148: initTc: unsolved constraints --------------------------------------+---------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: --------------------------------------+---------------------------------- || ghc: panic! (the 'impossible' happened) || (GHC version 8.0.2 for x86_64-unknown-linux): || initTc: unsolved constraints || WC {wc_insol = || [W] ltail_ae2e :: t_ae2d[tau:1] (CHoleCan: ltail) || [W] lhead_ae2h :: t_ae2g[tau:1] (CHoleCan: lhead)} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 09:23:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 09:23:22 -0000 Subject: [GHC] #14148: initTc: unsolved constraints In-Reply-To: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> References: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> Message-ID: <065.fdc61cdbddf252a2074ca1fed706b89c@haskell.org> #14148: initTc: unsolved constraints ----------------------------------+-------------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | 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: | ----------------------------------+-------------------------------------- Changes (by robertpergl): * Attachment "HOntoUML.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 09:29:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 09:29:36 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.60977e38dcd1ee1024ec7c7b23d2214d@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): On my journey through fusion land, I fell in love with the idea of stream fusion and spent quite some time thinking about the `concatMap` problem. Apart from the HERMIT approach based on rewriting a (albeit large) subset of `concatMap` calls, I think the solution lies in call-pattern specialisation of function arguments, as already recognised in section 6.2 of the [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/spec-constr.pdf original paper on call-pattern specialisation]. The paper goes on to argue that it's too brittle to have rules matching on lambda terms. But then again, I don't see why we even need a RULE matching on a specific lambda term (or even terms with `exprArity` > 0), as these things are pretty much unique everytime they occur. E.g., having a RULE deduplicate specialisations would probably not help much anyway. So, if we would employ some other mechanism than rewrite rules to specialise call sites, as I understand `SpecConstr` currently does, I think we would be fine, wouldn't we? At least this could get rid of the `concatMap` roadblock, are there any others I'm not aware of? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 09:40:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 09:40:34 -0000 Subject: [GHC] #14148: initTc: unsolved constraints In-Reply-To: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> References: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> Message-ID: <065.364465c002aaac540fa59426692b8b4b@haskell.org> #14148: initTc: unsolved constraints ----------------------------------+-------------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | ----------------------------------+-------------------------------------- Changes (by robertpergl): * version: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 09:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 09:56:41 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.a7a295f73c882a680a8265742c9243be@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf1337@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 10:39:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 10:39:37 -0000 Subject: [GHC] #14149: Tyepchecker generates top-level unboxed coercion Message-ID: <046.cedaffee7ff4ab48fd36761ff9f90f4f@haskell.org> #14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 this code {{{ {-# OPTIONS_GHC -fdefer-out-of-scope-variables #-} module Foo where import Data.Coerce f :: Bool f = coerce (k :: Int) }}} It generates a lint error: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** : warning: [RHS of cobox_a11N :: (Int :: *) ~R# (Bool :: *)] The type of this binder is unlifted: cobox_a11N Binder's type: (Int :: *) ~R# (Bool :: *) *** Offending Program *** $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Foo"#) cobox_a11N :: (Int :: *) ~R# (Bool :: *) [LclId[CoVarId]] cobox_a11N = typeError @ ('TupleRep '[]) @ ((Int :: *) ~R# (Bool :: *)) "Foo.hs:8:5: error:\n\ \ \\226\\128\\162 Couldn't match representation of type \\226\\128\\152Int\\226\\128\\153 with that of \\226\\128\\152Bool\\226\\128\\153\n\ \ arising from a use of \\226\\128\\152coerce\\226\\128\\153\n\ \ \\226\\128\\162 In the expression: coerce (k :: Int)\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = coerce (k :: Int)\n\ \(deferred type error)"# f :: Bool [LclIdX] f = (typeError @ 'LiftedRep @ Int "Foo.hs:8:13: error: Variable not in scope: k :: Int\n\ \(deferred type error)"#) `cast` (cobox_a11N :: (Int :: *) ~R# (Bool :: *)) *** End of Offense *** }}} Reason: this rather hacky test in `TcUnify.buildImplication` {{{ ; if null skol_tvs && null given && (not deferred_type_errors || not (isTopTcLevel tc_lvl)) }}} did take account of `Opt_DeferOutOfScopeVariables`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 10:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 10:41:57 -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.a987ab652d6ce06bc95cf0db3415d4e9@haskell.org> #14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Patch coming... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 10:42:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 10:42:43 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.83d9b678818ba0345428ddb6d0642735@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. That turned out to be a separate bug: #14149. I'll commit a fix for it shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 10:44:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 10:44:25 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.51e62be5a43ad11f60c3eae621cb4835@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > if we would employ some other mechanism than rewrite rules to specialise call sites I don't know what you have in mind here. Would you care to elaborate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 10:52:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 10:52:53 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.5b16476f80aa7fa2f3e8c63b3115589e@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:50 simonpj]: > > if we would employ some other mechanism than rewrite rules to specialise call sites > > I don't know what you have in mind here. Would you care to elaborate? Right, that's quite a bummer. I'll probably have to develop a deeper understanding of how `SpecConstr` and the rewrite rule mechanism works before I can answer this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 11:44:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 11:44:48 -0000 Subject: [GHC] #14142: Can't invert -dno-debug-output In-Reply-To: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> References: <046.cc80da7972a229aec5f9319432078ce1@haskell.org> Message-ID: <061.9cc9f5d13c745e6510ba43a1a64a72c9@haskell.org> #14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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:D3876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 12:48:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 12:48:03 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.42f900a482bf342bc7e4926f5f126c3f@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Saizan): This is great, but in some cases generating code for all the imported modules is too much. Would it make sense to have {-# OPTIONS_GHC -fobject-code #-} change the HscTarget for the module, so that authors can fine-tune for which modules code needs to be generated? (together the old behavior of -fno-code, I mean) Currently having that pragma seems to have no effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 13:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 13:53:55 -0000 Subject: [GHC] #14148: initTc: unsolved constraints In-Reply-To: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> References: <050.38e4cfa129243bfcdddc8099c5065d32@haskell.org> Message-ID: <065.5709a64593b78129a3f49417e91615bc@haskell.org> #14148: initTc: unsolved constraints ----------------------------------+-------------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Old description: > || ghc: panic! (the 'impossible' happened) > || (GHC version 8.0.2 for x86_64-unknown-linux): > || initTc: unsolved constraints > || WC {wc_insol = > || [W] ltail_ae2e :: t_ae2d[tau:1] (CHoleCan: ltail) > || [W] lhead_ae2h :: t_ae2g[tau:1] (CHoleCan: lhead)} New description: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] ltail_ae2e :: t_ae2d[tau:1] (CHoleCan: ltail) [W] lhead_ae2h :: t_ae2g[tau:1] (CHoleCan: lhead)} }}} -- Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. In 8.2.1, I get this error message instead: {{{ [3 of 4] Compiling Rendering ( app/Rendering.hs, dist/build/HOntoUML/HOntoUML-tmp/Rendering.o ) app/Rendering.hs:110:132: error: • Variable not in scope: ltail :: Text • Perhaps you meant ‘tail’ (imported from Prelude) | 110 | renderClippedEdge i1 i2 [textLabel $ mLabel2Label mLbl, HeadLabel (StrLabel m2), TailLabel (StrLabel m1), arrowTo noArrow, LTail ltail, LHead lhead] | ^^^^^ app/Rendering.hs:110:145: error: • Variable not in scope: lhead :: Text • Perhaps you meant ‘head’ (imported from Prelude) | 110 | renderClippedEdge i1 i2 [textLabel $ mLabel2Label mLbl, HeadLabel (StrLabel m2), TailLabel (StrLabel m1), arrowTo noArrow, LTail ltail, LHead lhead] | ^^^^^ app/Rendering.hs:113:40: error: • The constructor ‘OUAssocPHInst’ should have 1 argument, but has been given 3 • In the pattern: OUAssocPHInst mLbl (i1, m1) (i2, m2) In an equation for ‘renderAssocPHInst’: renderAssocPHInst ouModel ouModelInst (OUAssocPHInst mLbl (i1, m1) (i2, m2)) = renderClippedEdge i1 i2 [textLabel (ouphMetaLabel phMeta), TailLabel (StrLabel $ m1 <> "<" <> aggregType <> ">"), HeadLabel (StrLabel m2), ....] | 113 | renderAssocPHInst ouModel ouModelInst (OUAssocPHInst mLbl (i1, m1) (i2, m2)) = | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 14:11:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 14:11:28 -0000 Subject: [GHC] #13702: GHC can't produce position independent executables In-Reply-To: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> References: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> Message-ID: <061.c3b18676e810bfb4e98ba6df94292bf7@haskell.org> #13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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:D3589 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 14:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 14:34:51 -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.63cda28e3f427fdd5f45968aeaa77b30@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: | -------------------------------------+------------------------------------- Comment (by simonpj): ..and see #13905 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 14:47:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 14:47:11 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.b9f8ef41f487b0514f67695300a4336e@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider the example above: {{{ let ys = expensive in letrec f xs = case xs of [] -> ys (p:ps) -> p : f ps in f ps : qs }}} Here `f` is called exactly once in the body of the `letrec`, but not in tail position. Question: can cardinality analysis discover that `ys` is evaluated at most once? I would have thought the answer should be 'yes'. And if so, we can inline it, which is what we want. To make this go * We'd need to check that the cardinality analysis fixpoint stuff was up to snuff * We'd need to make the inliner take account of that used-once info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 16:56:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 16:56:07 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.a2b2c74686380afd9b672a6aa4c7781a@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): If anybody is unaware and interested: the latest work on the topic is "Stream Fusion, to Completeness" (https://strymonas.github.io/), and in Sec. 8 it seems to claim advantages relative to the HERMIT work (though I've only skimmed this), so that might be relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 17:51:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 17:51:43 -0000 Subject: [GHC] #14147: Confusing error messages with PolyKinds and superclasses In-Reply-To: <045.2f97dd08027b2520e8f15eafbacd4f3a@haskell.org> References: <045.2f97dd08027b2520e8f15eafbacd4f3a@haskell.org> Message-ID: <060.2217a335105d0629b18f030336a48b9c@haskell.org> #14147: Confusing error messages with PolyKinds and superclasses -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by enolan): OK, I'm willing to accept that code that compiles without `PolyKinds` shouldn't necessarily compile with it turned on. I still think this is a bad error message though. Yes, `k` is a variable that exists, but it's not one I wrote. From the user's perspective this message is very unhelpful. Perhaps something along these lines could be appended to the message when an error like this is emmited: "where k is an inferred kind parameter in Tagged's kind: `forall {k}. k -> * -> *`". Then I'd know where `k` comes from and can figure out that I can add a `Typeable` constraint for it or fix it at `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 18:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 18:02:52 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.eee2ed6bc98ba5e4f15065056558559a@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by enolan): * cc: enolan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 18:43:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 18:43:59 -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.05ba6950fa9493b8a8c4d6dc0bd42353@haskell.org> #14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * cc: duog (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 20:17:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 20:17:27 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.b7909dc6f26ace1cba993cc4208f861c@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ugh. Trying to change anything involving `bindLHsTyVarBndr` is proving to be a massive headache. There are numerous complications here that I'm not sure how to deal with: * Using `rnImplicitBinders` simply won't work in `bindHsQTyVars`. `rnImplicitBinders` expects an `LHsType GhcPs` as an argument, which `bindHsQTyVars` doesn't have. * Even if we did somehow pass an `LHsType GhcPs` to `rnImplicitBndrs` from `bindHsQTyVars`, I'm not convinced it would do the right thing. The problem: the `kv_bndrs` from `bindHsQTyVars` need to be bound using `newTyVarNameRn mb_assoc` (since the `kv_bndrs` might be from an associated class), but `rnImplicitBndrs` does nothing of the sort. * `bindLHsTyVarBndr` performs a validity check ([http://git.haskell.org/ghc.git/blob/7463a95dbe53d789f8f245f26735a7ac74bb6e11:/compiler/rename/RnTypes.hs#l974 here]) to ensure that a list of tyvar binders is well scoped (i.e., reject something like `forall (a :: k) k.`). But we can only perform this check because `bindLHsTyVarBndrs` keeps track of the kind variables that are implicitly bound so far, one by one, and communicates this information to each call to `bindLHsTyVarBndr` so that it can check if a binder is in the set of implicitly bound kind variables. If we removed `bindLHsTyVarBndr`'s ability to implicitly bind kind variables, I'm not sure how we'd perform this check at all. * Could we move this error check to `rnImplicitBndrs`? Perhaps, but then we'd need to migrate the code which tracks one-by-one all of the implicitly bound kind variables so far. That doesn't sound fun. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 21:53:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 21:53:59 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.7b4534ca01fa26cdbcbc34388192e720@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): That example is what #10918 is about. The Cardinality Analyser does not see that `ys` is evaluated at most once, but Call Arity does. We can make it inline, but the tricky bit is to prevent it from being floated out again. That’s what I feel that a `call` to a join point outside of `letrec` would be more explicit and more stable – although I see the clumsiness of that. There you write: > But it does seem hard. The float-out pass assumes, crudely, that it's good to float out a redex of any called-many lambda. But, as we see here, that's wrong for case branches that are only evaluated on one of those calls (the final one in this case). Not only is that info hard to record in the syntax tree, but it's also potentially quite fragile to program transformation, like other sorts of cardinality information. And a `call` to a join-point outside the `letrec` is so far the only way I can think of to “record it in the syntax tree” – but maybe there are better ways? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 23:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 23:13:25 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.19985c3bbd6a8ca008e9f8a465efbf17@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > That’s what I feel that a call to a join point outside of letrec would be more explicit Yes but it doesn't work in general. What if it was {{{ let ys = expensive in letrec f xs = case xs of [] -> ys : [] (p:ps) -> p : f ps in f ps : qs }}} Then `ys` is not a join point in any shape or form; but all the argument about being able to inline it is equally valid. I don't want to build a complicated infrastructure that only solves part of the problem! Ah, silly me. I was struck with a brilliant idea, and then realised that it's exactly what you describe in comment:12. Take any case alternative in the recursive function that does not mention the recursive function, and make it into a non-recursive join point, thus: {{{ letrec f xs = case xs of [p] -> e1 -- no f's (p:ps) -> e2[f] ===> let f as = join j p = e1 in joinrec f x = case xs of [p] -> j p (p:ps) -> e2[f] in f as }}} Now we can readily inline ys into e1 if `f` if called once (and hence the `\as` is marked one-shot. Moreover, it works for arbitary expressions e1. Of course you worked this out already a few days ago; I just didn't read carefully enough. Sorry. I acrually rather like it now, as a part of the loopification transformation. Still to think about * A remaining tricky point is that we need to stop one of these carefully- constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. Go for it! (But do these other simpler things first.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 23 23:54:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Aug 2017 23:54:34 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.9bac928717d445ccda1cce85e80e6a23@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I agree that having the ability to override the current behaviour would be useful, but I don't think that overloading -fobject-code to do it is right. I would suggest that we need an "-fno-code-auto" flag. Currently, when we are deciding which modules to codegen in GhcMake.enableCodegenForTH, we take all transitive dependencies of modules that use -XTemplateHaskell. We could instead take all transitive dependencies (where those dependencies don't disable -fno-code-auto) of modules that use -XTemplateHaskell. I think it would make sense to disable -fno-code-auto by default if we improved the error message to suggest it be enabled. One could just add {-# OPTIONS_GHC -fno-code-auto #-} to the modules that need to be codegenned. Separately, a flag -fno-code-target={default,interpreted,asm(?),llvm(?)} should perhaps be added to determine the method of codegen. This would enable us to use interpreted by default, again provided that errors from, for example, unboxed tuples, suggested the user change it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 04:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 04:08:31 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.3e05bc8b4e10ff1589eb9a255f309d8f@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Now a github proposal https://github.com/ghc-proposals/ghc- proposals/pull/63, see discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 05:33:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 05:33:56 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.3bbe6ff56b933ce275929e124bb12c5a@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by patrickdoc): What happens to the `mkUserGuidePart` code now? I seem to have left a bit of orphaned content laying around the build system and code comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:14:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:14:30 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) Message-ID: <050.081284759fbb3264e065177f36714c06@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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: -------------------------------------+------------------------------------- On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell. In GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to "exit" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!). (Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:15:09 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.b3b26b0d33433b1c67bc149a17cbb27e@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 RyanGlScott): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:39:56 -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.031fafdd897bf92d43c8a8484d0e9e79@haskell.org> #14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a211dca8236fb8c7ec632278f761121beeac1438/ghc" a211dca8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a211dca8236fb8c7ec632278f761121beeac1438" Fix defer-out-of-scope-variables In the hacky code in TcUnify.buildImplication we'd failed to account for -fdefer-out-of-scope-variables. See the new function TcUnify.implicationNeeded. Fixes Trac #14149 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:41:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:41:20 -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.49bc78c39c4d0c625b49e83533adfcca@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: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => testsuite/tests/typecheck/should_compile/T14149 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:41:49 -0000 Subject: [GHC] #14132: Report an error for a missing class instance before an error for type family instances of an associated type. In-Reply-To: <043.1281ae18d24cc16b799c87119536c685@haskell.org> References: <043.1281ae18d24cc16b799c87119536c685@haskell.org> Message-ID: <058.20123b384ae8828ee425133b7365b5e8@haskell.org> #14132: Report an error for a missing class instance before an error for type family instances of an associated type. -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: feature request | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK #14149 is fixed, so you can have another go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 13:47:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 13:47:21 -0000 Subject: [GHC] #14151: Invisible kind variable referenced in typeclass instance error message Message-ID: <049.e63f4c3b4971d48c01adefc2954743c1@haskell.org> #14151: Invisible kind variable referenced in typeclass instance error message -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Here is a minimal example: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} newtype HFix h a = HFix (h (HFix h) a) class EqForall f where eqForall :: f a -> f a -> Bool class EqHetero h where eqHetero :: (forall x. f x -> f x -> Bool) -> h f a -> h f a -> Bool instance EqHetero h => EqForall (HFix h) where eqForall (HFix a) (HFix b) = eqHetero eqForall a b instance EqHetero h => Eq (HFix h a) where (==) = eqForall }}} When we build this with GHC 8.2.1, we get the following error message: {{{ instance_head.hs:18:10: error: • Variable ‘k’ occurs more often in the constraint ‘EqHetero h’ than in the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Eq (HFix h a)’ | 18 | instance EqHetero h => Eq (HFix h a) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The error message is bad, although most people trying to do this kind of thing can probably reason that there is an invisible `k` and that `h :: (k -> Type) -> k -> Type` and that `a :: k`. I don't really see a way to improve it, but I thought I would bring it up. Also, should the typechecker even reject this? I don't have a great understanding of how GHC's restrictions for keep things decidable work, but a repeated invisible variable seems like it's a somewhat different thing than a repeated visible variable. I'm likely wrong about this, but I just wanted to raise the question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 14:54:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 14:54:07 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.9fb3a1e0b12eb63ee19fdb5dba559988@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this should get cleaned up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 14:59:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 14:59:04 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.dc57692043d9cb0eed7450752512c95f@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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): Phab:D3839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * owner: patrickdoc => (none) * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 14:59:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 14:59:30 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.e65d9b20a285d6426b9013d5b05f4400@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | 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): Phab:D3839, Wiki Page: | Phab:D3886 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D3839 => Phab:D3839, Phab:D3886 Comment: Here is a quick attempt at ripping it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:12:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:12:57 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.94727a204468410999c13ed3f56a3ee0@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Judging from the logic in `lintStgExpr` mention in the ticket description, it seems like GHC is supposed to maintain the invariant that we will not use the case binder in the RHS if it is an unboxed tuple or sum (e.g. a `MultiValAlt`). However, I can't find this invariant documented anywhere, nor do we seem to respect it. For instance, consider this example from compiling `TyCoRep`, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170824 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders w_sx0k :: Coercion, w69_sx0l :: InterestingVarFun, w70_sx0m :: VarSet, ww_sx0n :: [Var], ww1_sx0o :: VarSet] ww5_sx1u :: (# [Var], VarSet #) is out of scope }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:37:47 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions Message-ID: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14137 #10918 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of a discussion from #14137. == The problem == We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations. But sometimes the binding is only used inside the recursive function on the “exit path”. In which case it would be good to inline. Example: {{{#!hs let x = f x0 in let go 10 = h x go i = go (i+1) in go (0::Int) + 100 }}} It would be beneficial to inline `x`. The problem is that it is not very obvious that this occurence of `x` is ok for inlining. In particular, it is not syntactically visible. == Proposed solution == If we apply loopification (#14068), this would turn into {{{#!hs let x = f x0 in let go n = joinrec jgo 10 = h x jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''first joinrec normal form'', defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”. This ticket proposes to transform this even further and ''float out all case alternatives that do not mention `jgo` as non-recursive join- points'', as so: {{{#!hs let x = f x0 in let go n = join jexit = h x joinrec jgo 10 = call jexit jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''second `joinrec` normal form'', defined as “in first `joinrec` normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are join calls”. If the floated expression has free variables that are bound inside the `joinrec`, they turn into parameters of the newly created joinpoint. At this point, GHC can tell that `go` is called at most once, and will therefore happily inline `x` into the right hand side of `jexit. == Alternative solutions == Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and inline it even in the original code. This works, but the problem is that float-out will undo this. See [ticket:10918#comment:5]. == Limitation === It only works for recursive functions that are join points, or can be turned into join points by loopification (#14068). It does not work forexample for {{{#!hs let x = f x0 let go 0 = h x go n = (go (n-1) + 1 in go 10 }}} although it would be equally desirable to float `h x` out of `go` so that `x` can be inlined. == Preservation == A remaining tricky point is that we need to stop one of these carefully- constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. (Ticket #14137 is about inlining ''more'' join points into recursive join points, so it is the antithesis to the present ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:42:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:42:42 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.68c9c27628f35233b97d871becaef4eb@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ok, it’s high time time to split the discussions. The exit path join point idea is now at #14152, and this ticket can continue to explore the inlining of join-points into recursive join-points. In comment:14 you see three threads here. I do not quite see the difference between the first two threads you identified. Isn’t comment:7 precisely the “that one fix to OccurAnal [that] should do the job.” from the description? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:44:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:44:15 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.c3f45795c42819f732394c41e16ede80@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: 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): Ugh! If this doesn't happen for 8.2.2, I may have to revert the long- awaited `unordered-containers` upgrade. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:44:18 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.2cbca14a70113b06de657ae0c5459c00@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, always bringing `MultiVarAlt` binders into scope allows GHC to bootstrap with `-dstg-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 16:45:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 16:45:01 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.6b3a4a15a0ce311fad723da37b6564fc@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact 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 Thu Aug 24 17:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 17:20:29 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name Message-ID: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> #14153: Change worker thread name to something mentioning original process name ----------------------------------------+--------------------------------- Reporter: enolan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Worker OS thread are renamed to `ghc_worker` when spawned. This is annoying when reading debugging messages that print the process name. For example, at work I'm debugging a segfault in a Haskell program and the kernel message just says `ghc_worker[21992]: segfault at 0 ip...` which doesn't tell me which of our Haskell programs is having the problem. I'd like to change this so it mentions the original name. On Linux, we can get that from the `program_invocation_name` global. `pthread_setname_np` has a maximum length of 15 characters, so we'll have to truncate it. I propose the first 13 characters of the original name followed by ":w". I'd just as soon not change the name in the first place but apparently this change was made to make it easier to distinguish worker threads from the main thread when debugging processes in gdb (commit 674c631ea111233daa929ef63500d75ba0db8858). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 17:20:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 17:20:39 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name In-Reply-To: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> References: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> Message-ID: <060.516983e962ed5975d1f66cdf6812740d@haskell.org> #14153: Change worker thread name to something mentioning original process name -------------------------------------+------------------------------------- Reporter: enolan | Owner: enolan Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by enolan): * owner: (none) => enolan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 17:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 17:52:22 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.dad5310ab66017d2bd3814f3fa31a799@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: 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): AFAICT it shouldn't be too difficult to implement this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 17:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 17:55:45 -0000 Subject: [GHC] #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm In-Reply-To: <046.25ac2134055d26c6424aeecbae3f299a@haskell.org> References: <046.25ac2134055d26c6424aeecbae3f299a@haskell.org> Message-ID: <061.3118d05e9a37ff4a4b3ad20f454a3b10@haskell.org> #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13857 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #13857 Comment: It turns out this already exists as #13857. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 17:56:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 17:56:10 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.7e999e6bbaf4d0ba471b839ee2370ec9@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3888 * milestone: => 8.2.2 Comment: Actually, I just remembered I already have a WIP patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 18:39:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 18:39:36 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name In-Reply-To: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> References: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> Message-ID: <060.5a81e5b8697cec278e7cffd242442952@haskell.org> #14153: Change worker thread name to something mentioning original process name -------------------------------------+------------------------------------- Reporter: enolan | Owner: enolan Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree; I have found the `ghc_worker` name quite confusing in the past. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 19:41:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 19:41:01 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic Message-ID: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, PolyKinds #-} import Data.Coerce newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a deriving newtype Show class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn :: forall a i. a -> Swap f i i a ireturn = coerce (ireturn @f @a @i) instance IxPointed Ran where ireturn :: a -> Ran i i a ireturn a = Ran (\k -> k a) xs = case ireturn @(Swap Main.Ran) 'a' of Swap (Ran f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type 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 Aug 24 19:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 19:42:16 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.dd042b576842eda18a1c168298f39125@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{ > {-# Language RankNTypes, DerivingStrategies, TypeApplications, > ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, > PolyKinds #-} > > import Data.Coerce > > newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > Swap :: p g f a -> Swap p f g a > deriving newtype > Show > > class IxPointed m where > ireturn :: a -> m i i a > > instance IxPointed f => IxPointed (Swap f) where > ireturn :: forall a i. a -> Swap f i i a > ireturn = coerce (ireturn @f @a @i) > > instance IxPointed Ran where > ireturn :: a -> Ran i i a > ireturn a = Ran (\k -> k a) > > xs = > case ireturn @(Swap Main.Ran) 'a' of > Swap (Ran f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, PolyKinds #-} import Data.Coerce newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a deriving newtype Show class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn :: forall a i. a -> Swap f i i a ireturn = coerce (ireturn @f @a @i) instance IxPointed Ran where ireturn :: a -> Ran i i a ireturn a = Ran (\k -> k a) xs = case ireturn @(Swap Main.Ran) 'a' of Swap (Ran f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type 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 Aug 24 19:43:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 19:43:03 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.c31b89603de0755749f994212f9adf7c@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{#!hs > {-# Language RankNTypes, DerivingStrategies, TypeApplications, > ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, > PolyKinds #-} > > import Data.Coerce > > newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > Swap :: p g f a -> Swap p f g a > deriving newtype > Show > > class IxPointed m where > ireturn :: a -> m i i a > > instance IxPointed f => IxPointed (Swap f) where > ireturn :: forall a i. a -> Swap f i i a > ireturn = coerce (ireturn @f @a @i) > > instance IxPointed Ran where > ireturn :: a -> Ran i i a > ireturn a = Ran (\k -> k a) > > xs = > case ireturn @(Swap Main.Ran) 'a' of > Swap (Ran f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, PolyKinds #-} import Data.Coerce newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a deriving newtype Show class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn :: forall a i. a -> Swap f i i a ireturn = coerce (ireturn @f @a @i) instance IxPointed Ran where ireturn :: a -> Ran i i a ireturn a = Ran (\k -> k a) xs = case ireturn @(Swap Ran) 'a' of Swap (Ran f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type 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 Aug 24 19:55:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 19:55:13 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) Message-ID: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This one does me 'ead in, I accidentally type `Ran` instead of `Swap` {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, PolyKinds #-} import Data.Coerce newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a deriving newtype Show class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn :: forall a i. a -> Swap f i i a ireturn a = Ran (ireturn a) }}} and get this error {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) /tmp/bug.hs:17:15: error: • Couldn't match expected type ‘Swap f i i a’ with actual type ‘Ran g0 h0 a0’ • In the expression: Ran (ireturn a) In an equation for ‘ireturn’: ireturn a = Ran (ireturn a) In the instance declaration for ‘IxPointed (Swap f)’ • Relevant bindings include a :: a (bound at /tmp/bug.hs:17:11) ireturn :: a -> Swap f i i a (bound at /tmp/bug.hs:17:3) | 17 | ireturn a = Ran (ireturn a) | ^^^^^^^^^^^^^^^ /tmp/bug.hs:17:20: error: • Couldn't match a lifted type with an unlifted type Expected type: (a0 -> g0 b) -> h0 b Actual type: (->) (a0 -> g0 b) (a0 -> g0 b) a • In the first argument of ‘Ran’, namely ‘(ireturn a)’ In the expression: Ran (ireturn a) In an equation for ‘ireturn’: ireturn a = Ran (ireturn a) | 17 | ireturn a = Ran (ireturn a) | ^^^^^^^^^ Failed, modules loaded: none. }}} Is GHC right to bring up unlifted types? I would guess this is due to the newly added levity polymorphism of `(->) :: TYPE rep -> TYPE rep' -> Type` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 22:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 22:42:19 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.d8dbe3c848438b4a6840681eb266b4f7@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 bgamari]: > Hmm, it may be helpful to see what the additional bindings look like. This is when I would usually use my [[https://github.com/bgamari/ghc-dump |ghc-dump]] utility to dump a summary of the top-level bindings and their types. This should be easily diffable. Unfortunately, this seems ... challenging. I'm running the "before" version now. It's been going for many minutes, and is really chewing up disk space. In particular, `TextRegexTDFANewDFAEngine_FA.pass-0017.cbor` has already passed five gigabytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 22:46:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 22:46:40 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.e5f923436a8eb3a0e7214a1b3b52e6da@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > {{{#!hs > {-# Language RankNTypes, DerivingStrategies, TypeApplications, > ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, > PolyKinds #-} > > import Data.Coerce > > newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > Swap :: p g f a -> Swap p f g a > deriving newtype > Show > > class IxPointed m where > ireturn :: a -> m i i a > > instance IxPointed f => IxPointed (Swap f) where > ireturn :: forall a i. a -> Swap f i i a > ireturn = coerce (ireturn @f @a @i) > > instance IxPointed Ran where > ireturn :: a -> Ran i i a > ireturn a = Ran (\k -> k a) > > xs = > case ireturn @(Swap Ran) 'a' of > Swap (Ran f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, PolyKinds #-} module T14154 where newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a ireturn :: forall m i a. a -> m i i a ireturn = undefined xs = case ireturn @(Swap Ran) 'a' of Swap (Ran f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type 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 Aug 24 22:52:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 22:52:07 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.c1af4acb3b329567304fe9cf8e3f3f50@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > {{{#!hs > {-# Language RankNTypes, DerivingStrategies, TypeApplications, > ScopedTypeVariables, GADTs, PolyKinds #-} > > module T14154 where > > newtype Ran g h a > = Ran (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > Swap :: p g f a -> Swap p f g a > > ireturn :: forall m i a. a -> m i i a > ireturn = undefined > > xs = case ireturn @(Swap Ran) 'a' of > Swap (Ran f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, PolyKinds #-} module T14154 where newtype Ran g h a = MkRan (forall b. (a -> g b) -> h b) newtype Swap p f g a where MkSwap :: p g f a -> Swap p f g a ireturn :: forall m i a. a -> m i i a ireturn = undefined xs = case ireturn @(Swap Ran) 'a' of MkSwap (MkRan f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type 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 Aug 24 22:59:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 22:59:37 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.ec672de20f4bc8408638d5fa7dc879c6@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * version: 8.3 => 8.0.1 Old description: > {{{#!hs > {-# Language RankNTypes, DerivingStrategies, TypeApplications, > ScopedTypeVariables, GADTs, PolyKinds #-} > > module T14154 where > > newtype Ran g h a > = MkRan (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > MkSwap :: p g f a -> Swap p f g a > > ireturn :: forall m i a. a -> m i i a > ireturn = undefined > > xs = case ireturn @(Swap Ran) 'a' of > MkSwap (MkRan f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, TypeApplications, ScopedTypeVariables, GADTs, PolyKinds #-} module T14154 where newtype Ran g h a = MkRan (forall b. (a -> g b) -> h b) newtype Swap p f g a where MkSwap :: p g f a -> Swap p f g a ireturn :: forall m i a. a -> m i i a ireturn = undefined xs = case ireturn @(Swap Ran) 'a' of MkSwap (MkRan f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Comment: Interesting! This appears to be an old bug, since it happens all the way back in GHC 8.0.1 (that's as far back as I can go, since `TypeApplications` didn't exist before then). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 23:08:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 23:08:37 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.05be5a5b48762719d422cb91ee83ad20@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: Here's a simpler version which removes some cruft: {{{#!hs newtype R a = R ((a -> a) -> a) newtype Swap p f g a = Swap (p g f a) class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn a = R (ireturn a) }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:15: error: • Couldn't match expected type ‘Swap f i i a’ with actual type ‘R a’ • In the expression: R (ireturn a) In an equation for ‘ireturn’: ireturn a = R (ireturn a) In the instance declaration for ‘IxPointed (Swap f)’ • Relevant bindings include a :: a (bound at Bug.hs:9:11) ireturn :: a -> Swap f i i a (bound at Bug.hs:9:3) | 9 | ireturn a = R (ireturn a) | ^^^^^^^^^^^^^ Bug.hs:9:18: error: • Couldn't match a lifted type with an unlifted type • In the first argument of ‘R’, namely ‘(ireturn a)’ In the expression: R (ireturn a) In an equation for ‘ireturn’: ireturn a = R (ireturn a) • Relevant bindings include a :: a (bound at Bug.hs:9:11) ireturn :: a -> Swap f i i a (bound at Bug.hs:9:3) | 9 | ireturn a = R (ireturn a) | ^^^^^^^^^ }}} This is a regression form 8.0.2, where the error message didn't mention unlifted types: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:15: error: • Couldn't match expected type ‘Swap f i i a’ with actual type ‘R a’ • In the expression: R (ireturn a) In an equation for ‘ireturn’: ireturn a = R (ireturn a) In the instance declaration for ‘IxPointed (Swap f)’ • Relevant bindings include a :: a (bound at Bug.hs:9:11) ireturn :: a -> Swap f i i a (bound at Bug.hs:9:3) Bug.hs:9:18: error: • Couldn't match type ‘m0 (a -> a)’ with ‘(->)’ Expected type: (a -> a) -> a Actual type: m0 (a -> a) (a -> a) a • In the first argument of ‘R’, namely ‘(ireturn a)’ In the expression: R (ireturn a) In an equation for ‘ireturn’: ireturn a = R (ireturn a) • Relevant bindings include a :: a (bound at Bug.hs:9:11) ireturn :: a -> Swap f i i a (bound at Bug.hs:9:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 23:09:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 23:09:20 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.4e5c957c1f3b185353a9e456eb33b339@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: RyanGlScott (removed) * version: 8.0.1 => 8.3 Old description: > {{{#!hs > {-# Language RankNTypes, TypeApplications, > ScopedTypeVariables, GADTs, PolyKinds #-} > > module T14154 where > > newtype Ran g h a > = MkRan (forall b. (a -> g b) -> h b) > > newtype Swap p f g a where > MkSwap :: p g f a -> Swap p f g a > > ireturn :: forall m i a. a -> m i i a > ireturn = undefined > > xs = case ireturn @(Swap Ran) 'a' of > MkSwap (MkRan f) -> f print > }}} > > {{{ > $ ghci -ignore-dot-ghci /tmp/bug.hs > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.3.20170605 for x86_64-unknown-linux): > piResultTy > k0_a1Ki[tau:2] > b0_a1Kt[tau:2] > 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/types/Type.hs:949:35 in ghc:Type > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: {{{#!hs {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, PolyKinds #-} module T14154 where newtype Ran g h a = MkRan (forall b. (a -> g b) -> h b) newtype Swap p f g a where MkSwap :: p g f a -> Swap p f g a ireturn :: forall m i a. a -> m i i a ireturn = undefined xs = case ireturn @(Swap Ran) 'a' of MkSwap (MkRan f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] 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/types/Type.hs:949:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Comment: I have worked out what is happening here. * We have {{{ ireturn :: forall k (m :: k -> k -> * -> *) a (i :: k). a -> m i i a }}} * At the call of `ireturn` in `xs` we instantiate `k`,`m`,`a`,`i` with unification variables `k0`, `m0 :: k0 -> k0 -> k* -> *`, `a0`, `i0 :: k0`. * The visible type application ends up forcing `k0 := k1 -> *` * In the pattern `MkRan f` we end up with expected type `Ran k0 i0 i0 a0` * The definition of `Ran` is {{{ newtype Ran k (g :: k -> *) (h :: k -> *) a where MkRan :: forall k (g :: k -> *) (h :: k -> *) a. (forall (b :: k). (a -> g b) -> h b) -> Ran k g h a }}} * So, in `TcPat.tcDataConPat` we instantiate `k :-> k0, g :-> i0, h :-> i0, a :-> a0`. * But now, in the instantiated version of `MkRan`'s type we have `i0 b`, ''which is ill-kinded''. At least, it's ill-kinded until we zonk everything. But the type constraint solver calls `typeKind` on un-zonked types quite a bit. * `typeKind` is non-monadic and crashes on ill-kinded types, via the call to `piResultTy` {{{ typeKind (AppTy fun arg) = piResultTy (typeKind fun) arg }}} * FWIW the crashing call to `typeKind` is in `TcUnify.promoteTcType`. Now, I believe our invariant is that ''we never form an ill-kinded type'', zonked or unzonked. In this example we don't obey the invariant. What could we do? * In the offending `tcDataConPat` we could instantiate the data contructor's type with fresh unification variables, and emit equalities to link it up with the "expected" type `ctxt_res_tys`. * We could do that in the general case, but have a short-cut for the common case where the kinds do actually match up. * We could give up on the invariant; where we need `typeKind` and it fails, we could generate a unification variable, and emit a new kind of delayed constraint that means `kappa ~ kindof( ty )`. Yuk. Richard, any other ideas? What is unsettling is that I can't see how to be sure there are no other lurking cases of this same problem, elsewhere in the typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 23:16:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 23:16:40 -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.8597066bc309031158425feee6d505ba@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints Old description: > This is a spin off of a discussion from #14137. > > == The problem == > > We generally avoid inlining or floating a binding into a recursive > function, because we do not want to duplicat work/allocations. > > But sometimes the binding is only used inside the recursive function on > the “exit path”. In which case it would be good to inline. Example: > > {{{#!hs > let x = f x0 > in let go 10 = h x > go i = go (i+1) > in go (0::Int) + 100 > }}} > > It would be beneficial to inline `x`. > > The problem is that it is not very obvious that this occurence of `x` is > ok for inlining. In particular, it is not syntactically visible. > > == Proposed solution == > > If we apply loopification (#14068), this would turn into > > {{{#!hs > let x = f x0 > in let go n = > joinrec jgo 10 = h x > jgo i = call jgo (i+1) > in call jgo n > in go (0::Int) + 100 > }}} > > I’d like to call this ''first joinrec normal form'', defined as “every > recursive function where all recursive calls are tail-recursive is a > recursive join point”. > > This ticket proposes to transform this even further and ''float out all > case alternatives that do not mention `jgo` as non-recursive join- > points'', as so: > > {{{#!hs > let x = f x0 > in let go n = > join jexit = h x > joinrec jgo 10 = call jexit > jgo i = call jgo (i+1) > in call jgo n > in go (0::Int) + 100 > }}} > > I’d like to call this ''second `joinrec` normal form'', defined as “in > first `joinrec` normal form, and all subexpressions of a recursive join > point `j` that are in tail-call position and do not mention `j` are join > calls”. > > If the floated expression has free variables that are bound inside the > `joinrec`, they turn into parameters of the newly created joinpoint. > > At this point, GHC can tell that `go` is called at most once, and will > therefore happily inline `x` into the right hand side of `jexit. > > == Alternative solutions == > > Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and > inline it even in the original code. This works, but the problem is that > float-out will undo this. See [ticket:10918#comment:5]. > > == Limitation === > > It only works for recursive functions that are join points, or can be > turned into join points by loopification (#14068). It does not work > forexample for > > {{{#!hs > let x = f x0 > let go 0 = h x > go n = (go (n-1) + 1 > in go 10 > }}} > > although it would be equally desirable to float `h x` out of `go` so > that `x` can be inlined. > > == Preservation == > > A remaining tricky point is that we need to stop one of these carefully- > constructed non-recursive join points being inlined into a recursive join > point, even if it is invoked at just one place. That should not be hard. > And in a final run of the simplifer (or in CorePrep) we could switch off > that restriction and let it inline. (Ticket #14137 is about inlining > ''more'' join points into recursive join points, so it is the antithesis > to the present ticket.) New description: This is a spin off of a discussion from #14137. == The problem == We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations. But sometimes the binding is only used inside the recursive function on the “exit path”. In which case it would be good to inline. Example: {{{#!hs let x = f x0 in let go 10 = h x go i = go (i+1) in go (0::Int) + 100 }}} It would be beneficial to inline `x`. The problem is that it is not very obvious that this occurence of `x` is ok for inlining. In particular, it is not syntactically visible. == Proposed solution == If we apply loopification (#14068), this would turn into {{{#!hs let x = f x0 in let go n = joinrec jgo 10 = h x jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''first joinrec normal form'', defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”. This ticket proposes to transform this even further and ''float out all case alternatives that do not mention `jgo` as non-recursive join- points'', as so: {{{#!hs let x = f x0 in let go n = join jexit = h x joinrec jgo 10 = call jexit jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''second `joinrec` normal form'', defined as “in first `joinrec` normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are join calls”. If the floated expression has free variables that are bound inside the `joinrec`, they turn into parameters of the newly created joinpoint. At this point, GHC can tell that `go` is called at most once, and will therefore happily inline `x` into the right hand side of `jexit. == Alternative solutions == Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and inline it even in the original code. This works, but the problem is that float-out will undo this. See [ticket:10918#comment:5]. == Limitation == It only works for recursive functions that are join points, or can be turned into join points by loopification (#14068). It does not work forexample for {{{#!hs let x = f x0 let go 0 = h x go n = (go (n-1) + 1 in go 10 }}} although it would be equally desirable to float `h x` out of `go` so that `x` can be inlined. == Preservation == A remaining tricky point is that we need to stop one of these carefully- constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. (Ticket #14137 is about inlining ''more'' join points into recursive join points, so it is the antithesis to the present ticket.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 23:23:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 23:23:39 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.c78c55b5451698733ef6245078a80802@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This feels similar {{{#!hs -- /tmp/bug.hs:6:12-20: error: -- • Couldn't match kind ‘*’ with ‘GHC.Types.RuntimeRep’ -- When matching the kind of ‘'GHC.Types.LiftedRep’ -- • In the first argument of ‘R’, namely ‘(m `ibind`)’ -- In the expression: R (m `ibind`) -- In an equation for ‘lft’: lft m = R (m `ibind`) -- | -- 6 | lft m = R (m `ibind`) -- | ^^^^^^^^^ -- Failed, modules loaded: none. newtype R a = R ((a -> a) -> a) class IxMonad m where ibind :: (a -> m j k b) -> m i j a -> m i k b lft m = R (m `ibind`) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 24 23:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Aug 2017 23:26:21 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.cca70e3a8fc95c208e89ff02eb2aca2a@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I do not quite see the difference between the first two threads The original Description is about floating a non-join point into a nullary join point: {{{ let x = e in join j = Just x in ... }}} where this is the only occurrence of `x`. Here we want to transform to {{{ join j = Just e }}} so that the thunk creation occurs only if `j` is executed rather than always. But for nullary lets we do the reverse transform {{{ let x = Just e ===> let a = e in let x = Just e }}} for reasons described above. In contrast, the second thread is about inlining ''join points'', not about inlining ''lets''. And as I say in comment:14 I'm no longer so keen on this idea, esp in view of #14152 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 00:44:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 00:44:48 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.cb33e2768ddd114bf576819dd0239231@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: 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'd like to bring this up again. Especially since `Semigroup`, in the next two years, is going to end up as a superclass of `Monoid`. The even better instance would be: {{{ instance (Ord k, Semigroup v) => Monoid (Map k v) }}} In the mailing list that Joachim linked to, this kind of change seemed to attract pretty broad support. I think the only reasonable way to make this change without introducing silent breakage would be to release a `containers-0.6` in which `Map` has no `Monoid` instance. Then, in `containers-0.7`, the new instance would be introduced. This is precisely what Henning proposed in https://mail.haskell.org/pipermail/libraries/2012-April/017749.html, and I think it's the best option available for switching out this instance. These two release would need to be at least a year apart. We would probably like for their to be a stackage lts between them that had `containers-0.6`. And we would probably want to wait for `Semigroup` to actually become a superclass of `Monoid` in `base` before releasing `semigroups-0.7`, just because it's really annoying when you end up with a `(Semigroup v, Monoid v)` constraint sometimes. I would like to draw attention to the two arguments against making this change: 1. It would break a lot of other packages 2. The behavior value-combining `Monoid` instance is easily recovered by using `unionWith`. This reasoning roughly motivates this post: https://mail.haskell.org/pipermail/libraries/2012-April/017745.html Concerning argument (1), I offer no rebuttal. I'll only point out that, with stackage, we now have a somewhat convenient way to attempt to measure the breakage. But, no one has ever done this, and it might be worth looking into. Argument (2) I would like to challenge. In http://www.haskellforall.com/2014/07/equational-reasoning-at-scale.html, Gabriel Gonzalez uses, in a practical way, the behavior of data types that can lift monoidal value into another monoid. Things like: {{{ instance Monoid a => Monoid (IO a) instance (Monoid a, Monoid b) => Monoid (a,b) instance Monoid b => Monoid (a -> b) }}} These are useful because they give us `Monoid` instances for types like: {{{ Int -> Bool -> Char -> IO ([Text],Ordering) }}} The value-combining `Monoid` instance for `Map` is in this same spirit. It would allow us to trivially combine nested map with types like this: {{{ type M = Map Int (Map Char (Map PersonId (Map ItemId [Text]))) mappend :: M -> M -> M }}} This behavior can be recovered by `unionWith`, but it's a length explicit lifting: {{{ deepAppend :: M -> M -> M deepAppend = unionWith (unionWith (unionWith (unionWith (<>)))) }}} I plan on continuing this tomorrow. I have a little more to say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 01:54:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 01:54:52 -0000 Subject: [GHC] #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm In-Reply-To: <046.25ac2134055d26c6424aeecbae3f299a@haskell.org> References: <046.25ac2134055d26c6424aeecbae3f299a@haskell.org> Message-ID: <061.883a74bbdf4ae25a63dd5af6fdaea74a@haskell.org> #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13857 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"5f3d2d3be034e04ba872f2695ab6d7b75de66663/ghc" 5f3d2d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f3d2d3be034e04ba872f2695ab6d7b75de66663" CNF: Implement compaction for small pointer arrays Test Plan: Validate Reviewers: austin, erikd, simonmar, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, andrewthad, thomie, dfeuer GHC Trac Issues: #13860, #13857 Differential Revision: https://phabricator.haskell.org/D3888 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 01:54:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 01:54:52 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.d238a9d5b9695df4c11ce26b1a0c244b@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"5f3d2d3be034e04ba872f2695ab6d7b75de66663/ghc" 5f3d2d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f3d2d3be034e04ba872f2695ab6d7b75de66663" CNF: Implement compaction for small pointer arrays Test Plan: Validate Reviewers: austin, erikd, simonmar, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, andrewthad, thomie, dfeuer GHC Trac Issues: #13860, #13857 Differential Revision: https://phabricator.haskell.org/D3888 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 01:56:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 01:56:16 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.dd1216d5e1af33f7a437d91f5eb1bab1@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 02:14:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 02:14:02 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.403bb9771abbe15da2f59a64c896a6b2@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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 ezyang): * priority: normal => low Comment: > However, the current --make behaviour produces code that is at least as good(modulo the bug exhibited above), and in your first (A.hs-boot, B.hs, A.hs, C.hs) example, it is better! I wonder if it is possible to exploit laziness to always have unfoldings available even when importing an .hs- boot. Yes. But the price you pay is that the compilation of A and B can no longer be done in parallel. I tend to think of an hs-boot files as one way you could speed up compilation, a bit like header files, at the cost of the quality of optimized code. > It's the simplifier that is doing more inlining than it should, isn't it? (Not the typechecker.) Yes! > And how much does all this matter anyway? Not much, probably! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 02:15:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 02:15:07 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.d3cf5510f487f82c6ba621f27cb68180@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Thank you for the hard work inaki. Probably what is left to do now is someone (e.g., me) to do a full build with gi-gio and debug from there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 03:45:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 03:45:44 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.e4071e99f5f7f1cd73aeb7aeb546ea7a@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I was able to get enough to compare the results of `LiberateCase`. Things generally look the same at the top level, but after the `SetLevels` patch there's a bunch more local code. Everything is rather huge, so it's hard to see just what the deal is, but interestingly it really seems to be ''added'' code more than ''replaced'' code. Virtually everything that used to be there is still there, but now there's more. I'll attach diffable dump files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 03:53:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 03:53:37 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.7a04cfb4bb5680fa7c560cf923e03593@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "pre-set-levels.gz" added. Before setlevels patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 03:59:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 03:59:06 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.f10c3f58485e94e5d0b5c225f14737b8@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "post-set-levels.bz2" added. After setlevels patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 03:59:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 03:59:45 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.c567496c3b4aa3c708d185c4d53da88f@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 08:50:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 08:50:09 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.22b04a2260aae9bac8de042b421a2d8a@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType * priority: normal => highest * milestone: => 8.4.1 Comment: Aha. Based on comment:1 I very rapidly found that the constraint solver was going wrong thus. We have {{{ m :: k0 -> k0 -> * -> * i :: k0 }}} and a wanted constraint {{{ [W] (m i :: k0 -> * -> *) ~# ((->) LR LR :: * -> * -> *) }}} where `LR` is `LiftedRep`. This much is fine. But then the canonicaliser decomposes it thus {{{ [W] (i :: k0) ~# (LR :: *) [W] (m :: k0 -> k0 -> * -> *) ~# ((->) LR :: forall r. * -> TYPE r -> *) }}} which is utterly bogus. Presumably we need an extra guard in the `can_eq_app` that checks that neither function kind is a forall? Richard please comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 09:05:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 09:05:55 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.6391a54ebf9a43ddfb2d7687eb85e2fd@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it seems like GHC is supposed to maintain the invariant that we will not use the case binder in the RHS if it is an unboxed tuple or sum Ah. That is true after the Unarise pass, but not before. (That's a change we brought in a few years back.) E.g. we can write {{{ f :: (# Int, Bool #) -> Int f x = ... g :: Bool -> (# Int, Bool #) }}} and then call it thus {{{ f (g True) }}} By the time we translate to STG that'll look like {{{ case g True of (r :: (# Int, Bool #)) -> f r }}} and I think that's what is happening here. But the Unarise pass transforms it to {{{ case g True of (# (x::Int), (y::Bool) #) -> f x y }}} by making f take two explicit arguments. Can you check that the problem is gone after Unarise? It'd be ideal for STG lint to have a flag that checked the stronger invariant after Unarise. Incidentally, this should also be true of lambda binders, whether used or not; before Unarise they can be unboxed tuples, but not after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 09:29:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 09:29:31 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.35d3180c6f86777f1688866b86fef916@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > The original Description is about floating a non-join point into a nullary join point: That is happening in HEAD already (at least if I modify the example in comment:4 so that `ds5` occurs only in the join point `lvl6`, then `ds5` is floated into `lvl6`.) So maybe there is actually nothing to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 09:56:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 09:56:51 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.f238f351465360994ad3bd7964ccc148@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha! I tried {{{ module T14137 where f xs = let thunk = length xs j = Just thunk g 0 = j g n = g (n-1) in g 7 }}} Indeed, the inliner does not inline `thunk`, because of the lack of comment:3. But later `FloatIn` does push it inwards (it knows about join points); and the simplifier also knows not to float things out of join points. So all is well. Still, it's more direct to do it right away. I'll do it shortly because I'm meddling there anyway. That's all for this ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 10:17:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 10:17:56 -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.efce6e0fadcc6d2e8d421bc2cb11b629@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): I am wondering about the best place to perform this transformation. I could do it relatively easily as part of loopification (#14068), which I currently inserted between the occurrence analyser and the simplifier. But we also want to do it to `joinrec`s that are already `joinrec`s? The float out phase might also be a suitable place, since it – well – floats out expressions. Or maybe the simplifier itself (which has a notions of floating expressions, doesn’t it) can do it? Or should it be a pass of its own? Simon, what is your intuition here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 11:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 11:51:40 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.b875f3fd3b7b505aaf4b67a7537684e6@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: 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): What I'm trying to argue is that the two possible `Monoid` instances for `Map` aren't really equal in terms of how much they buy you. Let's look at merging nested `Map`s again. The question here is "how much code do I have to write to merge these?" Both for a deep merge and for a shallow merge. {{{ type M = Map Int (Map Char (Map PersonId (Map ItemId (Set Foo)))) -- Assuming the current Monoid instance of Map deep,shallow :: M -> M -> M deep = unionWith (unionWith (unionWith (unionWith (<>)))) shallow = (<>) -- Assuming the value-combining Monoid instance of Map deep,shallow :: M -> M -> M deep = (<>) shallow = union }}} My point is that the value-combining instance helps us more than the left- biased instance. Since the instances chain together, it's just one type we're getting a better `Monoid` instance for. It's any arbitrary nesting of them. Let's look at a situation where the left-biased instance fares a little better. What about the situations where you want a left-biased merge at the bottom of a nesting of `Monoid`s? So, not a nesting of `Map`s, but a nesting of other `Monoid`s with a `Map` at the bottom: {{{ type K = Int -> Char -> IO ([ParseError],Map PersonId Person) }}} The left-biased instance has the desirable behavior here. If, after have concatenated a bunch of expressions of type `K`, we try to parse two people with the same id, we silently discard the second one. But, we can easily recover this same behavior with the value-combining `Monoid` instance with: {{{ foo :: Int -> Char -> IO ([ParseError],Map PersonId (First Person)) }}} If you don't actually want that `First` newtype in your final result, it can be `coerce`d away safely as a noop. So, since the value-combining instance can express the left-biased instance, even in the worst cases, the semantics of the left-biased instance can be recovered by clever use of `coerce`. However, the reverse is not true. The left-biased instance cannot express the value-combining union, so currently when we want this, we have to step outside the realm of `Monoid` instances entirely and manually do the lifting. Just to emphasize the asymmetry in the amount and kind of code the end user must write: {{{ type J = Bar -> Baz -> IO ([Log], Map Pokemon (Set Attack)) type V = Bar -> Baz -> IO ([Log], Map Identifier Name) leftBiased :: V -> V -> V valueMerging :: J -> J -> J -- with the left-biased Monoid instance leftBiased = (<>) valueMerging v1 v2 a b = liftA2 (\(x1,y1) (x2,y2) -> (x1 <> x2, unionWith (<>) y1 y2)) (v1 a b) (v2 a b) -- with the value-merging Monoid instance type V' = Bar -> Baz -> IO ([Log], Map Identifier (First Name)) leftBiased a b = coerce ((coerce a) <> (coerce b :: V')) valueMerging = (<>) }}} I know using `coerce` isn't the prettiest thing, but notice that with the value-merging `Monoid` instance, we are able to leverage the automatic lifting of `Monoid` instances to give us a desired behavior. With the left-biased instance, we're stuck doing this by hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 11:57:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 11:57:23 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.091cd463e01be4e8b2610e389b897a11@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8649535c1c99b851ba3a9fd5a88ca0a3a28b2c18/ghc" 8649535/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8649535c1c99b851ba3a9fd5a88ca0a3a28b2c18" Don't do the RhsCtxt thing for join points This minor change fixes Trac #14137. It is described in Note [Join point RHSs] in OccurAnal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 11:57:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 11:57:23 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.c5ac5281833eb6f5e0419d36bfe91532@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"33452dfc6cf891b59d63fa9fe138b18cbce4df81/ghc" 33452dfc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="33452dfc6cf891b59d63fa9fe138b18cbce4df81" Refactor the Mighty Simplifier Triggered by #12150, and the knock-on effects of join points, I did a major refactoring of the Simplifier. This is a big patch that change a lot of Simplify.hs: I did a lot of other re-organisation. The main event ~~~~~~~~~~~~~~ Since the dawn of time we have had simplExpr :: SimplEnv -> InExpr -> SimplCont -> SimplM (SimplEnv, OutExpr) What's that SimplEnv in the result? When simplifying an expression the simplifier add floated let-bindings to the SimplEnv, extending the in-scope set appropriately, and hence needs to resturn the SimplEnv at the end. The mode, flags, substitution in the returned SimplEnv were all irrelevant: it was just the floating bindings. It's strange to accumulate part of the /result/ in the /environment/ argument! And indeed its leads to all manner of mysterious calls to zapFloats and transferring of floats from one SimplEnv to another. It got worse with join points, so I finally bit the bullet and refactored. Now we have simplExpr :: SimplEnv -> InExpr -> SimplCont -> SimplM (SimplFloats, OutExpr) -- See Note [The big picture] and the SimplEnv no longer has floats in it. The code is no shorter, but it /is/ easier to understand. Main changes * Remove seLetFloats field from SimplEnv * Define new data type SimplFloats, and functions over it * Change the types of simplExpr, simplBind, and their many variants, to follow the above plan Bottoming bindings ~~~~~~~~~~~~~~~~~~ I made one other significant change in SimplUtils (not just refactoring), related to Trac #12150 comment:16. Given x = where turns out to be a bottoming expression, propagate that information to x's IdInfo immediately. That's always good, because it makes x be inlined less (we don't inline bottoming things), and it allows (case x of ...) to drop the dead alterantives immediately. Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which calls CoreArity.findRhsArity, which already does simple bottom analysis. So we are generating the information; all we need do is to atach the bottoming info to the IdInfo. See Note [Bottoming bindings] Smaller refactoring ~~~~~~~~~~~~~~~~~~~ * Rename SimplifierMode to SimplMode * Put DynFlags as a new field in SimplMode, to make fewer monadic calls to getDynFlags. * Move the code in addPolyBind into abstractFloats * Move the "don't eta-expand join points" into tryEtaExpandRhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:02:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:02: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.1b89647fc321457e700447364f8ae0c6@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): Definitely not in the simplifier. FloatOut is already jolly complicated and I want to make it do NO FLOATING for join points. (There is currently a mess.) I'd suggest doing it as part of loopification. And I'd suggest NOT doing loopification with every occurrence analysis; that feels far too often to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:02:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:02:45 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.921d51750d41b8f83b06f537686db45c@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:03:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:03:10 -0000 Subject: [GHC] #14137: Do more inlining into non-recursive join points In-Reply-To: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> References: <046.258b5023aa2f795018ff0acd733d6c54@haskell.org> Message-ID: <061.258df98be1b601cb99fd9ea80e3d7f35@haskell.org> #14137: Do more inlining into non-recursive join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T14137 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T14137 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:03:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:03:56 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.a1d7bd268f4a2eee221848811fb1592f@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12150 Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => perf/compiler/T12150 * status: new => closed * resolution: => fixed Comment: It took longer than I thought but it's done now. The test program compiles fast again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:14:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:14:51 -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.4f181badbc1d62d541c32a1e59b7b4e9@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > And I'd suggest NOT doing loopification with every occurrence analysis; that feels far too often to me. The check of whether loopification can be done is pretty cheap, and falls out of Occurence Analysis anyways: I just check whether the occurrence info indicates that this is a recursive function that admits loopification: {{{ RecursiveTailCalled join_arity <- tailCallInfo occ }}} So don’t see a reason to check this every time. Once a binding is loopified, it is a recursive join point, and loopification does not look at it any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:16:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:16:10 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.bf939627bba3a0cbcaa71af3ff9b3ae7@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 trippels): https://github.com/jaor/xmobar/issues/310 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:20:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:20: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.2d3885379349b8da424e35bb5668ffad@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): Note to myself: == Common up identical exit paths I expect much code to look like this: {{{ let x = f x0 joinrec go 0 = h x go 10 = h x go 30 = if something then h x else call go (n-1) go 40 = if something then h (x+1) else call go (n-1) go n = call go (n-1) in call go 10 }}} where a recursive function checks a bunch of conditions and has the same exit code multiple times. Ih would be silly to create three joint points with `h x` as the right hand side. So when floating out these exit expressions, I plan to check if the same expression is already being floated out and use that join point, to get {{{ let x = f x0 join exit1 = h x join exit2 = h (x+1) joinrec go 0 = call exit1 go 10 = call exit1 go 30 = if something then call exit1 else call go (n-1) go 40 = if something then call exit2 else call go (n-1) go n = call go (n-1) in call go 10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:28:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:28:35 -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.7be6cddccb4fba02120af63dc21e2166@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > same exit code multiple times Or you could just rely on CSE to do this; it's set up to do precisely that. I think it works correctly for join points. (Can you check the latter point?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:38: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.c7a4b10fbd1ecb15ae34e11c574a158f@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > The check of whether loopification can be done is pretty cheap, and falls out of Occurence Analysis anyways Hmm. I just want to avoid an extra traversal on every single iteration. I suppose you could just do it as ''part'' of occurrence analysis? The occurrence analyser doesn't generally change the structure of the code; but it does do so in one situation; it drops dead code to improve the occurrence info on other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 12:47:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 12:47:21 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.7a38e54c6ace7e9945a5362953409a79@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree that a monoidal-combining `Map` is much nicer than our current `Map` (and usually what I find I need); I have been a proponent of this change in the past and even maintain the `monoidal-containers` library wrapping `containers` with these semantics. However, my impression is that argument (1) mentioned in comment:8 alone is enough to sink this proposal in many people's minds. In fact, with a few years of experience behind me since last looking at this, I may even agree. I don't think it is realistic to expect that we will be able to easily discern broken packages in a large scale study; breakage due to semantic changes like this can be very hard to spot. In the best case you have a use-site where the value type has no `Semigroup` instance, in which case the change will elicit a compile-time error. However, in the case where you do have an instance on-hand you will see silent breakage, which may or may not be evident in the runtime behavior of the program or test failures. Moreover, with the ubiquity of packages with lax handling of upper bounds will likely make managing such a change challenging, even if breakage can be readily identified; even a super-major version bump will have no effect on a package that has no bounds at all. Unfortunately, I suspect the only way we can make this change happen is via the introduction of new interfaces and not changing those that we already have. This may be via continuing to use `monoidal-containers` and others (e.g. `reducers`), although I admit that this isn't a terribly great option. Perhaps we could discuss merging a wrapper like `monoidal- containers` into `containers` (and, perhaps, `unordered-containers`). The good news is that with Backpack we are now slightly better equipped to provide such parallel interfaces; unfortunately it will likely be several years before we can rely on Backpack for a critical package like `containers`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 13:16:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 13:16:07 -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.ce284cb6be4f6464b2caa3f3165b3d1d@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 nad): I managed to trigger this bug using Agda version 2.6.0-439fe3e, built using GHC 8.2.1 with profiling enabled and `-fprof-auto`: {{{ $ agda_p --version +RTS -hb Agda version 2.6.0-439fe3e agda_p: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.2.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 13:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 13:34:26 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.d0f12feb3cb4eb9ca67ba4a578c50484@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm confused. If it passes all test cases, precisely when does the ASSERT failure happen? Does it happen in HEAD? How can someone else reproduce your problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 13:40:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 13:40:18 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.92dafbb2d854041da257746f4330116e@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: 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): * Attachment "simpl-INLINE-patch" added. WIP on floating from stable unfoldings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 13:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 13:50:52 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.4fb652fe7b40174a683ccc91d0e94c56@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: 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): * Attachment "occ-anal-rules-patch" added. WIP on occurrence analysis and rules -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 13:51:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 13:51:27 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.041f5af83129eb1014dea1776e6fb41e@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: 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 attached patches are not finished; they were just WIP related to the comments above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 14:08:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 14:08:23 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.2ed40d534f1088ac7b174287641cbf51@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't get this. I tried {{{ {-# LANGUAGE BangPatterns #-} module T14079 where e1 :: (Int, Int) -> Int -> (Int, Int) e1 !x y | y > 0 = x | otherwise = e1 x (y + 1) e2 :: (Int, Int) -> Int -> Int -> (Int, Int) e2 x y n = je x y where je !x y | y > 0 = x | otherwise = je x (y + n) }}} As you say I get a w/w split for `e1`. So if `e1` is called applied to two arguments I'll inline the wrapper and good things will happen. For for `e1` I get something good too {{{ e2 :: (Int, Int) -> Int -> Int -> (Int, Int) [GblId, Arity=3, Caf=NoCafRefs, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=False) Tmpl= \ (x_a1VH [Occ=Once] :: (Int, Int)) (y_a1VI [Occ=Once] :: Int) (n_a1VJ [Occ=OnceL!] :: Int) -> joinrec { je_s2nz [Occ=LoopBreakerT[2]] :: (Int, Int) -> Int -> (Int, Int) [LclId[JoinId(2)], Arity=2, Unf=OtherCon []] je_s2nz (x1_a1VL [Occ=Once!] :: (Int, Int)) (y1_a1VM [Occ=Once!] :: Int) = case x1_a1VL of x2_X1VS { (_ [Occ=Dead], _ [Occ=Dead]) -> case y1_a1VM of { GHC.Types.I# x3_a2mT -> case GHC.Prim.># x3_a2mT 0# of { __DEFAULT -> jump je_s2nz x2_X1VS (case n_a1VJ of { GHC.Types.I# y2_a2nf [Occ=Once] -> GHC.Types.I# (GHC.Prim.+# x3_a2mT y2_a2nf) }); 1# -> x2_X1VS } } }; } in jump je_s2nz x_a1VH y_a1VI}] e2 = \ (x_a1VH :: (Int, Int)) (y_a1VI :: Int) (n_a1VJ :: Int) -> case x_a1VH of { (ww1_s2ox, ww2_s2oy) -> case y_a1VI of { GHC.Types.I# ww4_s2oC -> joinrec { $wje_s2oE [InlPrag=[0], Occ=LoopBreaker] :: Int -> Int -> GHC.Prim.Int# -> (Int, Int) [LclId[JoinId(3)], Arity=3, Str=m, Unf=OtherCon []] $wje_s2oE (ww5_X2oV :: Int) (ww6_X2oX :: Int) (ww7_X2p2 :: GHC.Prim.Int#) = case GHC.Prim.># ww7_X2p2 0# of { __DEFAULT -> case n_a1VJ of { GHC.Types.I# y1_a2nf -> jump $wje_s2oE ww5_X2oV ww6_X2oX (GHC.Prim.+# ww7_X2p2 y1_a2nf) }; 1# -> (ww5_X2oV, ww6_X2oX) }; } in jump $wje_s2oE ww1_s2ox ww2_s2oy ww4_s2oC } } }}} `e2`'s strictness signature says that it has the CPR property. It doesn't have a w/w split, but it'll be inlined wherever it is used. Just to check, I tried this {{{ f1 x y = e1 x (y+1) f2 x y n = e2 x (y+t) n where t = length (reverse (reverse (reverse (reverse (reverse (reverse [1..n])))))) }}} The definition `t` is just make `f2` big enough so that the strictness analyser will do a w/w split for it. Sure enough, good things happen {{{ T14079.$wf2 [InlPrag=[0]] :: Int -> Int -> GHC.Prim.Int# -> GHC.Prim.Int# -> (# Int, Int #) [GblId, Arity=4, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 289 0}] T14079.$wf2 = \ (ww_s30e :: Int) (ww1_s30f :: Int) (ww2_s30j :: GHC.Prim.Int#) (ww3_s30n :: GHC.Prim.Int#) -> case GHC.List.$wlenAcc @ Int (GHC.List.reverse1 @ Int (GHC.List.reverse1 @ Int (GHC.List.reverse1 @ Int (GHC.List.reverse1 @ Int (GHC.List.reverse1 @ Int (GHC.List.reverse1 @ Int (GHC.Enum.eftInt 1# ww3_s30n) (GHC.Types.[] @ Int)) (GHC.Types.[] @ Int)) (GHC.Types.[] @ Int)) (GHC.Types.[] @ Int)) (GHC.Types.[] @ Int)) (GHC.Types.[] @ Int)) 0# of ww4_a2Yy { __DEFAULT -> joinrec { $wje_s308 [InlPrag=[0], Occ=LoopBreaker] :: Int -> Int -> GHC.Prim.Int# -> (# Int, Int #) [LclId[JoinId(3)], Arity=3, Str=, Unf=OtherCon []] $wje_s308 (ww5_s301 :: Int) (ww6_s302 :: Int) (ww7_s306 :: GHC.Prim.Int#) = case GHC.Prim.># ww7_s306 0# of { __DEFAULT -> jump $wje_s308 ww5_s301 ww6_s302 (GHC.Prim.+# ww7_s306 ww3_s30n); 1# -> (# ww5_s301, ww6_s302 #) }; } in jump $wje_s308 ww_s30e ww1_s30f (GHC.Prim.+# ww2_s30j ww4_a2Yy) } -- RHS size: {terms: 22, types: 23, coercions: 0, joins: 0/0} f2 [InlPrag=INLINE[0]] :: (Int, Int) -> Int -> Int -> (Int, Int) [GblId, Arity=3, Caf=NoCafRefs, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s309 [Occ=Once!] :: (Int, Int)) (w1_s30a [Occ=Once!] :: Int) (w2_s30b [Occ=Once!] :: Int) -> case w_s309 of { (ww1_s30e [Occ=Once], ww2_s30f [Occ=Once]) -> case w1_s30a of { GHC.Types.I# ww4_s30j [Occ=Once] -> case w2_s30b of { GHC.Types.I# ww6_s30n [Occ=Once] -> case T14079.$wf2 ww1_s30e ww2_s30f ww4_s30j ww6_s30n of { (# ww8_s30I [Occ=Once], ww9_s30J [Occ=Once] #) -> (ww8_s30I, ww9_s30J) } } } }}] f2 = \ (w_s309 :: (Int, Int)) (w1_s30a :: Int) (w2_s30b :: Int) -> case w_s309 of { (ww1_s30e, ww2_s30f) -> case w1_s30a of { GHC.Types.I# ww4_s30j -> case w2_s30b of { GHC.Types.I# ww6_s30n -> case T14079.$wf2 ww1_s30e ww2_s30f ww4_s30j ww6_s30n of { (# ww8_s30I, ww9_s30J #) -> (ww8_s30I, ww9_s30J) } } } } }}} This all looks fine to me. Are you sure there is a problem here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 14:42:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 14:42:02 -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.42d93de648d1ad95a25a73ee38c1b1dc@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 nad): I managed to make the test case a bit smaller: {{{ $ cat Main.hs import System.Exit main = exitSuccess $ ghc --make -prof Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main +RTS -hb Main: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.2.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 15:01:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 15:01:59 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.69b6915ca95fe90354e7a4d21de8f220@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): About my branch - It builds with `make` (with below steps) - It passes all tests (except the two mentioned in #14126) by using `make test`. - But, it does NOT build with `./validate`(with below steps). About HEAD, - It builds with `make` (with below steps) - It passes all the tests (except the two mentioned in #14126) by using `make test`. - It also builds with `./validate`. As I said earlier, > I suspect (as hinted above) it has to do with a bug in the renamer when dealing with orphan instances (and probably in conjunction with boot files). The easiest way (that I can think of now) to reproduce my problem is to clone my branch, and run `./validate`. @alanz could also reproduce this problem. Here are my exact steps for validating: 1. cloning my [https://github.com/shayan-najd/GrowableGHC branch] 2. `cd ghc` 3. ./validate Here are my exact steps for building and testing: 1. cloning my [https://github.com/shayan-najd/GrowableGHC branch] 2. `cd ghc` 3. `cp mk/build.mk.sample mk/build.mk` 4. set `BuildFlavour = devel2` and then 5. ./boot 6. ./configure 7. make -j4 8. THREADS=4 make test" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 15:13:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 15:13:35 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.7adae19aac93b019a4b33bb07d3bb72d@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ben could you possible look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 15:17:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 15:17:37 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.3b3c84a306a1ef4b1034838c97cc8449@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I did mean "instantiate the head shape with unification variables". In our example, the head shape is `T a [a]`. So, when checking `T1`, I instantiate the head shape with unification varibles `T alpha [alpha]` and unify with the result of the data con `T Bool [Bool]`. Success, and the substitution for alpha tells me about the necessary equality constraints. The payoff is that the rigid bits of the head shape get to instantiate any kind-unification-variables floating around in the result type of the data constructor. So this has to be done before we kind-generalise the data constructor's type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 15:32:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 15:32:00 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.1e370f85b3e67232ea0a44edb721b178@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: 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 absolutely agree that making the change in a way that silently introduces errors would be bad. That's why my proposal was to remove the instance first and then replace it later. With a major-version bump, the `Monoid` instance would be removed entirely. Then, everything depending on in would fail loudly. There would be no `Monoid` instance at all for probably 18-24 months. Let's say that it was `containers-0.6.0` that removed the instance. Eventually, stackage, nixpkgs, and the Haskell Platform would all pick up `containers-0.6.0` and put some pressure of their users to stop using the `Monoid` instance for `Map`. Then, after everyone's code was updated, the next release could introduce the new instance. Most of the breakage would be really easy to fix. Additionally, it should all be compile-time failures. The only silent breakage that could happen would be if someone didn't update their dependencies for two years and then tried to switch straight from the old `containers` to the newest one. I suspect this situation would be uncommon (although, as someone would is primarily an application developer, I certainly cannot speak for everyone on this, and I may be wrong about this, which would destroy my argument for this approach). So basically, I just wanted to clarify that while there would be breakage, none of it would be silent. Obviously, this still has to be weighed, but I think it's much less bad than the undetectable semantic changes you describe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:07:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:07:52 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.474516ebb0c0503d8fefcdee5bb43ac1@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3889 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3858 => Phab:D3889 Comment: Here is a patch fixing the linter to only check the invariant post- unarisation. > Incidentally, this should also be true of lambda binders, whether used or not; before Unarise they can be unboxed tuples, but not after. The StgLinter considers any `StgLam` expression to be an error, so this case should already be covered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:09:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:09:04 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.3d0dd3d62fea4406d310d7ea10255a8e@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #13938 may be another manifestation. It'd be good to nail this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:10:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:10:24 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.1019c192f9b1beb19cf03ba3c330686c@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3889 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The StgLinter considers any StgLam expression to be an error, so this case should already be covered. I meant the binders in `StgRhsClosure`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:13:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:13:21 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.d00c937941d954a1a648d854971efb10@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > Are you sure there is a problem here? No, not very sure. I guess I was confused by trying to hunt down the regression. (I am still not convinced that there is no case where without loopification, CPR happens, but with loopification, CPR does not happen because the function can now be inlined, but after inlining CPR does still not happend, and thus we get more allocations. But I cannot easily reproduce such a case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:13:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:13:30 -0000 Subject: [GHC] #14079: Failure to do CPR in the presence of a local letrec In-Reply-To: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> References: <046.8af6cb3349d29a577641f136d6a13c0d@haskell.org> Message-ID: <061.16631c3e46e766c7f59b88de09eefd22@haskell.org> #14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: invalid | 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 nomeata): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:30:27 -0000 Subject: [GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs In-Reply-To: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> References: <044.bc6bd53988312c04c5367a38ecd65b9f@haskell.org> Message-ID: <059.76eaf881adde0a1b711f75a9cd600908@haskell.org> #14081: 8.2.1 runghc from Windows x32 segfaults an all programs ----------------------------------+------------------------------ Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 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 in 5a1ae9e32535fe4a891a515d44dd13968161ff27. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:35:45 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.b204eb2c591cf902319d3a4d5df735a5@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Phab:D3815 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged with acde16b879b08dff6f1f01d3dede04771f533256. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:36:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:36:39 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.7960ed42a230bf79c281bdfa99bc7778@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | ffi/should_compile/T14125, | ffi/should_compile/T14125a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged with d9e2cf05d5cc79b680a5a75be17263b154a3a53d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:37:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:37:52 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.a26d9dcea8fa589684054390ea59f97c@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: ORF 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:D3718 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 77dab28d9bac76b0f0e5e4aae52b7ee683849e04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:39:34 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm In-Reply-To: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> References: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> Message-ID: <061.11a9087f8b915767afb9d3a897edf560@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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:D3787 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: It turns out that the other approach wasn't as simple as I was hoping it would be; keeping the approach in comment:3. Merged to `ghc-8.2` as 93a68595ea27e1c77df0c3092ab706ecd9695299. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 16:39:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 16:39:45 -0000 Subject: [GHC] #14082: -ddump-json does not escape quotes properly In-Reply-To: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> References: <050.ccfd7ec9a8f246536d61a78d93188591@haskell.org> Message-ID: <065.69b64fda10e7ff5770dc1229c4ef7153@haskell.org> #14082: -ddump-json does not escape quotes properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: JSON 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: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 3920225b39e83f8a759218b6ab5411cac7c80df1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:18:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:18:40 -0000 Subject: [GHC] #11963: GHC introduces kind equality without TypeInType In-Reply-To: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> References: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> Message-ID: <060.9d7e1faec633335fb0688b0918a0f521@haskell.org> #11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 18dee8912f6afdcf13073d3d95d85513c14180e3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:19:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:19:03 -0000 Subject: [GHC] #14125: Bogus unacceptable type in foreign declaration. In-Reply-To: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> References: <045.573d395a0ac8c1b93172ffad961b7ddb@haskell.org> Message-ID: <060.a9e150657d89c622a7b1e18d18c007fc@haskell.org> #14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler (FFI) | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | ffi/should_compile/T14125, | ffi/should_compile/T14125a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:22:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:22:44 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.b00c4db76bd03870d422f6ba257d352a@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | unboxedsums/T14051 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with fe5350561dccb1913c2bdde2cd76d5513350b2cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:23:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:23:39 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.8f9f0f1a4a3e6e88c8ab22f6db8f3423@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: fixed | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 6712904886070df03887a47448100593c55fc1ff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:24:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:24:38 -0000 Subject: [GHC] #14075: GHC panic with parallel make In-Reply-To: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> References: <044.f6295c99539bfe782af0a9b387aa9f0c@haskell.org> Message-ID: <059.80122959d1ed703273ae714bc707e776@haskell.org> #14075: GHC panic with parallel make -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Phab:D3815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:25:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:25:07 -0000 Subject: [GHC] #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives Message-ID: <047.f2c9ff19f88b7125b374c0a479720f9e@haskell.org> #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the TSem documentation I saw this: Note that TSem has no concept of fairness, and there is no guarantee that threads blocked in waitTSem will be unblocked in the same order; in fact they will all be unblocked at the same time and will fight over the TSem. Hence TSem is not suitable if you expect there to be a high number of threads contending for the resource. Is this true for all the STM primitives? If so can this be clarified in the documentation for each primitive? Or in the main STM module page and each primitive referring to it. This is an important aspect of the behavior which I believe can sometimes be very important for the user of the library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 19:26:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 19:26:07 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.2265dc56578fcfc00d6300abb7c74d5b@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T14000 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Old description: > {{{ > {-# LANGUAGE TypeFamilies #-} > class C a where > type T a > c :: a -> T a > main = c noSuchThing > }}} > > yields: > {{{ > test_bad_error.hs:6:1: error: > • Couldn't match expected type ‘T a’ with actual type ‘T a0’ > NB: ‘T’ is a type function, and may not be injective > The type variable ‘a0’ is ambiguous > • In the ambiguity check for the inferred type for ‘main’ > To defer the ambiguity check to use sites, enable > AllowAmbiguousTypes > When checking the inferred type > main :: forall a. T a > }}} > > This makes simple out-of-scope error seem very perplexing and is a huge > regression in error quality. New description: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where type T a c :: a -> T a main = c noSuchThing }}} yields: {{{ test_bad_error.hs:6:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a }}} This makes simple out-of-scope error seem very perplexing and is a huge regression in error quality. -- Comment: Merged to `ghc-8.2` with a0558a5af9bdba208b629d04d729849166f565fd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 21:56:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 21:56:25 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.26cb450b2e3b1d4a287c8f29a29d7887@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a67b66e663d159c219750a5044ccf553c4b21bdb/ghc" a67b66e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a67b66e663d159c219750a5044ccf553c4b21bdb" Add strict variant of iterate Summary: This closes the nearly-eight-year-old #3474. Test Plan: Validate Reviewers: RyanGlScott, austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #3474 Differential Revision: https://phabricator.haskell.org/D3870 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 21:57:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 21:57:40 -0000 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@haskell.org> Message-ID: <057.0116497cad2752b9f22ec1d64bc56be3@haskell.org> #3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 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:D3870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 25 23:56:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Aug 2017 23:56:58 -0000 Subject: [GHC] #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives In-Reply-To: <047.f2c9ff19f88b7125b374c0a479720f9e@haskell.org> References: <047.f2c9ff19f88b7125b374c0a479720f9e@haskell.org> Message-ID: <062.4235bb55bff7f0b5b2024f13846e85b2@haskell.org> #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: stm 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 agree that the documentation should be more explicit about this. I suspect (bit am not certain) that the answer is that none of the primitives go guarantee fairness. Patches welcome (after confirmation, of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 03:45:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 03:45:43 -0000 Subject: [GHC] #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives In-Reply-To: <047.f2c9ff19f88b7125b374c0a479720f9e@haskell.org> References: <047.f2c9ff19f88b7125b374c0a479720f9e@haskell.org> Message-ID: <062.04ca45bef5686c39b179cf881a52c60f@haskell.org> #14156: Document the thread wakeup/scheduling/fairness semantics for the STM primitives -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/stm | Version: 8.2.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: stm => * component: libraries (other) => libraries/stm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 03:47:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 03:47:23 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.971fac54be74182d23471f6f6ac45911@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 03:59:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 03:59:02 -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.7d3f4d8dff8682e9ddec5336fa47e1c6@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 bgamari): I can reproduce this on Debian 8 using the i386 GHC 8.2.1 bindist and test program from comment:17. However, I can't reproduce this on x86-64, which should serve as a nice hint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:08:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:08:58 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.b924e3c90cfe81fa220194e65a65449f@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * milestone: => 8.2.2 Comment: Surprisingly, I'm having trouble even getting as far as Shayan reports. Instead I'm seeing renaming failures while building stage1, namely during `HsExpr.hs`: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 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 SyntaxExpr which was lazily initialized by initIfaceTcRn, I tried to tie the knot, but I couldn't find SyntaxExpr 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:1689:23 in ghc:TcIface }}} I am able to reproduce this with both 8.0.2 and 8.2.1-rc3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:11:30 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) Message-ID: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- [https://hackage.haskell.org/package/reflection-2.1.2/docs/Data- Reflection.html#v:give give] from the ''reflection'' library has the following type {{{#!hs give :: forall a r. a -> (Given a => r) -> r }}} but `flip give :: r -> a -> r`! This works with our own `Given`, `give` {{{ $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> class Given a Prelude> give :: a -> (Given a => r) -> r; give = undefined Prelude> :t flip give flip give :: c -> a -> c Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:12:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:12:12 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) In-Reply-To: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> References: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> Message-ID: <066.76614fdc534519c8edeff967f38c973d@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > [https://hackage.haskell.org/package/reflection-2.1.2/docs/Data- > Reflection.html#v:give give] from the ''reflection'' library has the > following type > > {{{#!hs > give :: forall a r. a -> (Given a => r) -> r > }}} > > but `flip give :: r -> a -> r`! > > This works with our own `Given`, `give` > > {{{ > $ ghci -ignore-dot-ghci -XRankNTypes > GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help > Prelude> class Given a > Prelude> give :: a -> (Given a => r) -> r; give = undefined > Prelude> :t flip give > flip give :: c -> a -> c > Prelude> > }}} New description: [https://hackage.haskell.org/package/reflection-2.1.2/docs/Data- Reflection.html#v:give give] from the ''reflection'' library has the following type {{{#!hs give :: forall a r. a -> (Given a => r) -> r }}} but `flip give :: r -> a -> r`! Same happens with our own `Given`, `give` {{{ $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> class Given a Prelude> give :: a -> (Given a => r) -> r; give = undefined Prelude> :t flip give flip give :: c -> a -> c Prelude> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:20:06 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) In-Reply-To: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> References: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> Message-ID: <066.75398de874f8e1edaa9ded33b50f6399@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: This isn't limited to `flip`, since you can also trigger similar behavior with a simple redefinition of `give`: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :set -XRankNTypes λ> class Given a λ> let give :: a -> (Given a => r) -> r; give = undefined λ> let f x y = give x y λ> :type +v f f :: a -> p -> p λ> :type f f :: a -> p -> p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:23:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:23:30 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) In-Reply-To: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> References: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> Message-ID: <066.461c405edc7db52117f7d56f1368f3ef@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: RyanGlScott (removed) Comment: This looks like correct behavior to me. Presumably, you want `flip give :: (Given a => r) -> a -> r`, but getting that would require impredicativity. The results GHC provides seem in accordance with, e.g., [http://cs.brynmawr.edu/~rae/papers/2016/type-app/visible-type-app.pdf this paper]. It is similar with the definition of `f`. Presumably, you want `f` to have the same type as `give`, but that would require inferring a higher-rank type, something that GHC avoids. Do close if you agree with this analysis. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 15:52:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 15:52:54 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.e2fe72a4f10ce3dec544b9c3e9d78806@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Strangely enough I'm unable to reproduce the issue I reported in comment:5 in another environment. Instead I reproduce the issue reported by Shayan. I'll continue investigation there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:19:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:19:18 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.8d37538ca96a3cbfb243dd0e6d7e441d@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 Iceland_jack): I'll keep it, I want to add another example I that could be derived {{{#!hs newtype Foo a = Foo (forall xx. Show a => IO xx) deriving newtype Alternative instance Functor Foo where instance Applicative Foo where }}} currently we can write this mess {{{#!hs instance Alternative Foo where empty :: Foo a empty = Foo (coerce (empty @IO @xx) :: forall xx. IO xx) (<|>) :: Foo a -> Foo a -> Foo a Foo a <|> Foo b = Foo (coerce ((<|>) @IO @xx a b) :: forall xx. IO xx) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:32:38 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.ad48613353339fc58400956578fcf915@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems like there is a bit of inconsistency regarding whether or not a module can be in its own `dep_orphs`. `TcRnDriver.tcRnImports` seems to suggest that `imp_orphs` (from which `DsUsage.mkDependencies` derives `dep_orphs`) can contain the current module due to `hs-boot`s, {{{#!hs -- Load any orphan-module (including orphan family -- instance-module) interfaces, so that their rules and -- instance decls will be found. But filter out a -- self hs-boot: these instances will be checked when -- we define them locally. -- (We don't need to load non-orphan family instance -- modules until we either try to use the instances they -- define, or define our own family instances, at which -- point we need to check them for consistency.) ; loadModuleInterfaces (text "Loading orphan modules") (filter (/= this_mod) (imp_orphs imports)) }}} However, the assertion in `RnNames.calculateAvails` (which is what Shayan reports) obvious disagrees: {{{#!hs orphans | orph_iface = ASSERT2( not (imp_sem_mod `elem` dep_orphs deps), ppr imp_sem_mod <+> ppr (dep_orphs deps) ) imp_sem_mod : dep_orphs deps }}} Looking at `mkDependendies`, it seems that we explicitly filter the currently module out of `imp_dep_mods`, {{{#!hs let dep_mods = modDepsElts (delFromUFM (imp_dep_mods imports) (moduleName mod)) -- M.hi-boot can be in the imp_dep_mods, but we must remove -- it before recording the modules on which this one depends! -- (We want to retain M.hi-boot in imp_dep_mods so that -- loadHiBootInterface can see if M's direct imports depend -- on M.hi-boot, and hence that we should do the hi-boot consistency -- check.) }}} We do not do the same thing for `dep_orphs`; I wonder if this should change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:37:04 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.34e72cb7cbb39e5cd05ed809ccb4fbdd@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | QuantifiedContexts, 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 RyanGlScott): Quantified contexts wouldn't make that example work. There's a bigger problem with that example in that there's no way for GHC to reason about how it should be derived. To pick a slightly simpler example: {{{ λ> newtype Foo a = Foo (forall xx. Show a => IO xx) deriving newtype Functor :7:67: error: • Can't make a derived instance of ‘Functor Foo’ with the newtype strategy: cannot eta-reduce the representation type enough • In the newtype declaration for ‘Foo’ }}} This error message hints at the fundamental limitation here that `GeneralizedNewtypeDeriving` faces. Let's describe algorithmically what GND is doing on a simple example: {{{#!hs class C (a :: * -> *) newtype N a = N (UnderlyingType a) deriving newtype C }}} First, in order for this to work about, one must be able to drop a type variable from `N`, since the last parameter to `C` is of kind `* -> *`. We //can// do this, so everything is good so far. But there's another issue: GHC wants to emit an instance like this: {{{#!hs instance => C N }}} What should `` be? To determine this, GHC must be able to take `UnderlyingType a`, eta reduce one type variable from it, attach `C` in front, and simplify. For instance, if `UnderlyingType a` is `Identity a`, then GHC would first emit: {{{#!hs instance C Identity => C N }}} And then simplify `C Identity` as much as possible. (For instance, if there is a `C Identity` instance in scope, the derived instance would simplify down to just `instance C N`.) But if `UnderlyingType a = forall xx. Show a => IO xx`, this won't work out, since `a` can't be eta reduced! (The ability to eta reduce a type is really a property that only certain types exhibit, such as data type constructors.) Not even an `unsafe newtype` strategy would help you here, since the issue doesn't concern typechecking code, but rather coming up with the code that needs to be typechecked in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:37:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:37:50 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.18711b49c69308c4b7b8c5c7e35355fa@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): Thank you for looking into this. I am still puzzled on why it builds with `make` (with `devel2`) but fails with `validate`. Is it because `ASSERT`s are all ignored using `make`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:42:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:42:10 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.0f7f2fe9e08c3b797d01be68c9ce6369@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:8 Shayan-Najd]: > Thank you for looking into this. > I am still puzzled on why it builds with `make` (with `devel2`) but fails with `validate`. > Is it because `ASSERT`s are all ignored using `make`? > The `devel2` build flavour builds only the stage 2 compile with assertions enable (specifically by defining the `DEBUG` macro). `validate`, on the other hand, enables assertions when building stage 1. Here, however, we are seeing the assertions fail in a run of the stage1 compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:47:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:47:07 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic Message-ID: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XTypeApplications GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> import qualified Control.Category as Cat Prelude Cat> :t (Cat.id @(->) >>=) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTy_maybe a0_a1qW[tau:2] a0_a1qW[tau:2] 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/types/Type.hs:699:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Cat> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:48:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:48:03 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails Message-ID: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> #14159: Decomposition of path sometimes fails ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The path decomposition sometimes fails in SysTools with an `INVALID_FUNCTION` error. The fall back method never executes because of the unexpected raised exception. This makes the Windows tarballs a but unpredictable when placed in random folders and starting up from random cwd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 16:52:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 16:52:11 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.346058de0add30b96ad6b2cc4de82d67@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe the testcase in Phab:D3890 should demonstrate this issue. There is also the question of whether `mkDependencies` also needs to remove the current module from `dep_finsts`. I suspect so as `calculateAvails` asserts the same invariant there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 17:28:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 17:28:41 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails In-Reply-To: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> References: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> Message-ID: <059.38cc2b68bce7abd6399665e53b633dc9@haskell.org> #14159: Decomposition of path sometimes fails ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 17:29:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 17:29:04 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails In-Reply-To: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> References: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> Message-ID: <059.48ae4ef53b9b5d2efbdcba1d341f117d@haskell.org> #14159: Decomposition of path sometimes fails ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3891 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3891 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 20:18:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 20:18:53 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.fd3fe26e2de024cec9f26f82bb9cd28d@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3892 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 20:46:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 20:46:27 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 Message-ID: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- A regression reported by [https://www.reddit.com/r/haskell/comments/6w7grz/type_inference_breaking_change_in_ghc_802/ Milewski], {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where import Data.Profunctor proj :: Profunctor p => forall c. (forall a. p a a) -> p c c proj e = e f1 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f1 f e = dimap f id (proj e) }}} The regression is that these used to work, but do not currently {{{#!hs -- • Couldn't match type ‘p c0 c0’ with ‘forall a1. p a1 a1’ -- Expected type: p c0 c0 -> p a a -- Actual type: (forall a1. p a1 a1) -> p a a -- • In the second argument of ‘(.)’, namely ‘proj’ -- In the expression: dimap id f . proj -- In an equation for ‘f2’: f2 f = dimap id f . proj -- • Relevant bindings include -- f2 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 24:1) f2 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f2 f = dimap id f . proj -- • Cannot instantiate unification variable ‘a0’ -- with a type involving foralls: (forall c. p c c) -> p a b -- GHC doesn't yet support impredicative polymorphism -- • In the expression: undefined -- In an equation for ‘f3’: f3 f = undefined -- • Relevant bindings include -- f :: a -> b -- (bound at 39:4) -- f3 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 39:1) f3 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f3 f = undefined -- dimap id f . proj }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 21:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 21:47:53 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.3b1f26cc0c933ff2c3c3fd4f397247d9@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > A regression reported by > [https://www.reddit.com/r/haskell/comments/6w7grz/type_inference_breaking_change_in_ghc_802/ > Milewski], > > {{{#!hs > {-# LANGUAGE RankNTypes #-} > module Test where > > import Data.Profunctor > > proj :: Profunctor p => forall c. (forall a. p a a) -> p c c > proj e = e > > f1 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b > f1 f e = dimap f id (proj e) > }}} > > The regression is that these used to work, but do not currently > > {{{#!hs > -- • Couldn't match type ‘p c0 c0’ with ‘forall a1. p a1 a1’ > -- Expected type: p c0 c0 -> p a a > -- Actual type: (forall a1. p a1 a1) -> p a a > -- • In the second argument of ‘(.)’, namely ‘proj’ > -- In the expression: dimap id f . proj > -- In an equation for ‘f2’: f2 f = dimap id f . proj > -- • Relevant bindings include > -- f2 :: (a -> b) -> (forall c. p c c) -> p a b > -- (bound at 24:1) > f2 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b > f2 f = dimap id f . proj > > -- • Cannot instantiate unification variable ‘a0’ > -- with a type involving foralls: (forall c. p c c) -> p a b > -- GHC doesn't yet support impredicative polymorphism > -- • In the expression: undefined > -- In an equation for ‘f3’: f3 f = undefined > -- • Relevant bindings include > -- f :: a -> b > -- (bound at 39:4) > -- f3 :: (a -> b) -> (forall c. p c c) -> p a b > -- (bound at 39:1) > > f3 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b > f3 f = undefined -- dimap id f . proj > }}} New description: A regression reported by [https://www.reddit.com/r/haskell/comments/6w7grz/type_inference_breaking_change_in_ghc_802/ Milewski], {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where import Data.Profunctor proj :: Profunctor p => forall c. (forall a. p a a) -> p c c proj e = e f1 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f1 f e = dimap f id (proj e) }}} Where these definitions no longer type check {{{#!hs -- • Couldn't match type ‘p c0 c0’ with ‘forall a1. p a1 a1’ -- Expected type: p c0 c0 -> p a a -- Actual type: (forall a1. p a1 a1) -> p a a -- • In the second argument of ‘(.)’, namely ‘proj’ -- In the expression: dimap id f . proj -- In an equation for ‘f2’: f2 f = dimap id f . proj -- • Relevant bindings include -- f2 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 24:1) f2 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f2 f = dimap id f . proj -- • Cannot instantiate unification variable ‘a0’ -- with a type involving foralls: (forall c. p c c) -> p a b -- GHC doesn't yet support impredicative polymorphism -- • In the expression: undefined -- In an equation for ‘f3’: f3 f = undefined -- • Relevant bindings include -- f :: a -> b -- (bound at 39:4) -- f3 :: (a -> b) -> (forall c. p c c) -> p a b -- (bound at 39:1) f3 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f3 f = undefined -- dimap id f . proj }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 26 22:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Aug 2017 22:18:21 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.3a1e27b3c4d3a2dc9521695723da6259@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | ImpredicativeTypes 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: => ImpredicativeTypes Comment: I grant that this breakage is surprising, but it is somewhat expected. The nub of the issue is once again impredicativity. For the sake of being explicit, here is a version of the above code with no external dependencies (please make an effort to do this in future bug reports - it makes dissecting the problem much easier): {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where class Profunctor p where dimap :: (a -> b) -> (c -> d) -> p b c -> p a d proj :: Profunctor p => forall c. (forall a. p a a) -> p c c proj e = e f1 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f1 f e = dimap f id (proj e) }}} Now it's worth noting that `f2`: {{{#!hs f2 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f2 f = dimap id f . proj }}} Has //never// typechecked, even on old versions of GHC. The only thing from this program that used to typecheck is `f3`: {{{#!hs f3 :: Profunctor p => (a -> b) -> (forall c. p c c) -> p a b f3 f = undefined }}} Really, the issue can be condensed down to just this: {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where -- Typechecks f :: (forall a. a) -> b f x = x -- Typechecks on GHC 7.10.3, but not later versions g :: (forall a. a) -> b g = undefined }}} {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Bug.hs, interpreted ) Ok, modules loaded: Test. λ> :q Leaving GHCi. $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Test ( Bug.hs, interpreted ) Bug.hs:10:5: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall a. a) -> b GHC doesn't yet support impredicative polymorphism • In the expression: undefined In an equation for ‘g’: g = undefined • Relevant bindings include g :: (forall a. a) -> b (bound at Bug.hs:10:1) Failed, modules loaded: none. }}} The fact that the error message mentions impredicativity should be a solid clue that we're headed into murky territory. The issue is that we're trying to instantiate a type variable with `(forall a. a) -> b`, which of course is impredicative. GHC 7.10.3 and earlier, for whatever reason, allowed this, but it made type inference much more unpredictable, as noted in https://ghc.haskell.org/trac/ghc/ticket/12749#comment:2. GHC 8.0 prevented this unpredictability by preventing type variables from being instantiated with polytypes, but at the cost of disallowing functions like `g`. For what it's worth, I don't think the solution is to re-allow `g`, but to instead allow a limited form of impredicativity that Simon Peyton Jones suggests in https://mail.haskell.org/pipermail/ghc- devs/2016-September/012940.html. That is, we would allow writing polytypes in visible type arguments, so this would be permissible: {{{#!hs g :: (forall a. a) -> b g = undefined @_ @((forall a. a) -> b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 07:00:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 07:00:52 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.6203b5d24bc0036f6100d23db75a7a1d@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: ak3n => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 07:53:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 07:53:10 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump Message-ID: <049.21b450e0015031856247b17c581564ea@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using the latest self compiler ghc ghc -O -ddump-to-file -ddump-parsed-ast with the file https://raw.githubusercontent.com/h4ck3rm1k3/gcc- ontology/master/tests/example_python_ast_in_haskell.hs After 2 hours I stopped it : PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 1.000t 0.014t 0 D 3.3 94.0 108:29.80 ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 08:07:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 08:07:15 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.9833afd5540e6219c8c6a2cb6a9423a2@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | 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 h4ck3rm1k3): /usr/local/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.3.20170819 git log : commit 1cdceb9fa3bc3ad01b2d840caad8e735513e14ed Author: Ben Gamari Date: Sat Aug 19 07:44:13 2017 -0400 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 19:11:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 19:11: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.d5d2b4fe158455ef7960aec7e6b69c46@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): I implemented this transformation; pushed to `wip/T14152` for storage. Don’t review the code too harshly yet, in particular feeding a list of fresh uniques to `maybeLoopify` is a temporary crutch. Observations so far: * Right now I am running this only after loopification. But that is unsatisfactory:[[BR]][[BR]]If we want this, we certainly also want it for functions that are `joinrec` to start with… but where? [[BR]][[BR]] Note that we need access to fresh uniques; this rules out the occurrence analyzer which is currently pure. * Currently, we get the desired transformation, but the next iteration of the simplifier gets rid of it again, in three different ways: * `preInlineUnconditionally` inlines them because they are values, so `canInlineInLam` is true. * `postInlineConditionally` inlines them because they are marked as “work free”. * `completeCall` does inlining at the call-site, again because they are marked as “work free”. It is not clear to me how to fix it. It is not false that they are work-free, and we certainly want to inline these join-points into non- recursive uses (should they for some reason appear). I agree with Simon that floating these things out and keeping them out feels “wrong” in the sense that it fights against the usual working of the simplifier. So maybe back to the drawing board and thinking harder how we can tell the simplifier that it is safe to inline something into the exit path ''inside'' the recursive function, and keep it there? Could we somehow syntactically mark exit paths using a new form of ticks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 21:32:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 21:32:42 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.a3111f5e402908f3e3050d1fa74474df@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #3081 Comment: These interrupt handlers have been rather flaky but the code hasn't changed the 8 years since they were written I think. The runtime will immediately kill the process if it receives two ctrl+c after each other. I suspect that something with threading is messing up again and handling the same event twice. But will need to investigate to be sure, but seems related to #3081 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 21:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 21:36:31 -0000 Subject: [GHC] #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint In-Reply-To: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> References: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> Message-ID: <063.f4b03e7f07c973bc803d87f6a735ec9c@haskell.org> #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC accepts | (amd64) invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Windows => Unknown/Multiple * component: Compiler => Compiler (Type checker) Comment: Thanks for the report, reclassifying it as this isn't a Windows specific error and I'm not too familiar with this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:41:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:41:21 -0000 Subject: [GHC] #14162: Core Lint error Message-ID: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Options_GHC -dcore-lint #-} {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, TypeFamilies, GADTs, TypeInType #-} import Data.Kind data family Sing (a :: k) data SubList :: [a] -> [a] -> Type where SubNil :: SubList '[] '[] Keep :: SubList xs ys -> SubList (x ': xs) (x ': ys) Drop :: SubList xs ys -> SubList xs (x ': ys) data instance Sing (x :: SubList ys xs) where SSubNil :: Sing SubNil SKeep :: Sing x -> Sing (Keep x) SDrop :: Sing x -> Sing (Drop x) }}} running it gives a massive core lint error, attached as a `lint.log`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:41:57 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.b81500c8267935cd5999e79d7aa6a2d4@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "lint.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:42:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:42:08 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.7b418138133a636a091e596d578f032e@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): bgamari: What is your approach for fixing this? Do you think it could be adapted to address the hs-boot visibility problems in trac:14092? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:42:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:42:43 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.50b91bb3f1110064347a7e06b6f52e38@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): From trying to compile Richard's [https://github.com/goldfirere/effects/blob/master/Effects.hs Effects.hs] with `-dcore-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:43:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:43:20 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.f48662b068c621c89a73f386e630c78d@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{#!hs > {-# Options_GHC -dcore-lint #-} > > {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, > TypeFamilies, GADTs, TypeInType #-} > > import Data.Kind > > data family Sing (a :: k) > > data > SubList :: [a] -> [a] -> Type where > SubNil :: SubList '[] '[] > Keep :: SubList xs ys -> SubList (x ': xs) (x ': ys) > Drop :: SubList xs ys -> SubList xs (x ': ys) > > data instance > Sing (x :: SubList ys xs) where > SSubNil :: Sing SubNil > SKeep :: Sing x -> Sing (Keep x) > SDrop :: Sing x -> Sing (Drop x) > }}} > > running it gives a massive core lint error, attached as a `lint.log`. New description: {{{#!hs {-# Options_GHC -dcore-lint #-} {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, TypeFamilies, GADTs, TypeInType #-} import Data.Kind data family Sing (a :: k) data SubList :: [a] -> [a] -> Type where SubNil :: SubList '[] '[] Keep :: SubList xs ys -> SubList (x ': xs) (x ': ys) Drop :: SubList xs ys -> SubList xs (x ': ys) data instance Sing (x :: SubList ys xs) where SSubNil :: Sing SubNil SKeep :: Sing x -> Sing (Keep x) SDrop :: Sing x -> Sing (Drop x) }}} running it gives a massive core lint error, attached as `lint.log`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 27 22:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Aug 2017 22:50:21 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.e93157333b3afb59cd1c9dc78ad6d3ce@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:3 ezyang]: > Yes. But the price you pay is that the compilation of A and B can no longer be done in parallel. I tend to think of an hs-boot files as one way you could speed up compilation, a bit like header files, at the cost of the quality of optimized code. > I find this very convincing. Do you think this is a controversial view? > > It's the simplifier that is doing more inlining than it should, isn't it? (Not the typechecker.) > > Yes! > The typechecker is providing the Ids with too many unfoldings attached though, right? Also see the example in comment 1 where a program typechecks because it can see a name that should be hidden to it. > > And how much does all this matter anyway? > > Not much, probably! > This is of interest to me because I am working on --make mode (trac:14095, trac:14103), and the treatment of hs-boot modules is by far the trickiest part. It seems that the correct behaviour isn't very well specified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 00:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 00:05:42 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.110cb02ef52fb41d0ccd20a89655fcdb@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by ezyang): > I find this very convincing. Do you think this is a controversial view? Not controversial per se, but most people who use hs-boot files only do so because they must use it to break an import loop. So it's not really a common way to use hs-boot files. > The typechecker is providing the Ids with too many unfoldings attached though, right? Technically, unfolding attachment happens during interface loading (called "typechecking the interface", but no real "typechecking" really takes place.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 04:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 04:07:42 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.6cea973e795ab554fb0c50155f481006@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer * milestone: => 8.2.2 Comment: I think I have a decent guess about what might be going on here. It looks like there's lots and lots of recursive string concatenation going on. Let me see if I can fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 07:07:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 07:07:10 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.32929596b5c465aae4e3f152b51dcc9e@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | 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 dfeuer): Actually, that's only one piece of the puzzle. Another major problem is that when `showAstData` is called in `HscMain`, its (`String`) result is converted to an `SDoc` using `text`. In order to even think about rendering that result, `Pretty` calculates its length. This forces the entire dump to be built in memory as a `String`. I don't have enough memory to do that on my system! I'm working on a patch to make `showAstData` produce a `Doc` right from the start rather than a `String`. Initial experiments suggest that this has a much better chance of working. One question: when should one produce a `Doc` and when should one produce an `SDoc`? I'm pretty unclear on that bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 08:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 08:00:07 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.c789e1979ab2ecefa2b434e2fc074d47@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | 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 dfeuer): Yep, my patch fixes this problem. I just need to figure out the `Doc`/`SDoc` business and I can upload a differential. My patched version produces somewhat different formatting (I'm no pretty printing expert), but it doesn't look horrible or anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 08:10:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 08:10:22 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.91b57fd5f3abcba48f4d56c1f2aa1bfd@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: => Phab:D3894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 08:20:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 08:20:53 -0000 Subject: [GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c In-Reply-To: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> References: <045.38941551ba7a39a68f2742fda11e6cc8@haskell.org> Message-ID: <060.ac886e06057fbcf3a34610f8b692a788@haskell.org> #14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > I tend to think of an hs-boot files as one way you could speed up compilation FWIW I have never thought of hs-boot files that way. Just as a 9not terribly satisfactory) way to break module loops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 09:19:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 09:19:55 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.05aa865e2703e59e2b87c6f115d18511@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a simpler version {{{ {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, TypeFamilies, GADTs, TypeInType #-} module T14162 where import Data.Kind data SubList :: Maybe a -> Type where SubNil :: SubList 'Nothing data family Sing (a :: k) data instance Sing (x :: SubList ys) where SSubNil :: Sing SubNil }}} There's an ASSERT error in `substTy` too, if you compile with a -DDEBUG compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 10:33:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 10:33:35 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.abcba2beea1f283e9cc9de762b1b122a@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: new Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by h4ck3rm1k3): Noob question, I cannot see this branch on the git://git.haskell.org/ghc.git and for some reason I cannot fetch from the phab : git fetch https://phabricator.haskell.org/diffusion/GHC/glasgow-haskell- compiler.git fatal: unable to access 'https://phabricator.haskell.org/diffusion/GHC /glasgow-haskell-compiler.git/': The requested URL returned error: 500 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 12:00:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 12:00:31 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.58cfc6a86b2651a15687f8c44ee752b9@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: Edward is the expert here. Edward: might you look at Ben's proposed fix? If correct, it needs a careful Note along the lines of the Summary of Phab:D3892. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:01:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:01:39 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.1434e8e1798cc9489ea8241684fcf58f@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: 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): Agreed that this is an "improvement" (as in, GHC is behaving closer to spec) from previous behavior. Yes to allowing polytypes in visible type arguments. No to accepting `g = undefined`. It's impredicative! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:03:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:03:23 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) In-Reply-To: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> References: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> Message-ID: <066.ddb8dfda8817d07a4bf581a3c34178d7@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:04:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:04:27 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.aecb1144f533327274c70a4621c044a5@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: 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): In that case, it sounds like this particular bug is resolved as "wontfix". We don't yet have a ticket for implementing the ability to visibly apply polytypes—should this ticket become that, or should we open a new one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:11:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:11:54 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.a52b08c43f0131716ffa040dad9cff6d@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah. Now I understand better. Instantiating the shape is just incidental, done so that unification succeeds at all. The real action is in solving for any metavars in the data constructor type, and this unification does ''not'' affect anything about the head shape. Yes, that sounds reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:13:25 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.48cb7c43935f2ac2ee3c30328eb997f9@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: 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'd say a new one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:19:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:19:50 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.ba1989dc4593ebaa7d3971ce9f37bd7d@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 RyanGlScott): Actually, I want to take back my proposal in comment:3. My idea relies on the ability to put "bang patterns" on variable binders, which is something that simply isn't possible anywhere else. (We could change the pattern variable binders to be proper patterns and only allow them to be variables or variables adorned with bangs, but that would be an exceedingly strange design.) In light of this, I would suggest that we endorse explicitly bidirectional pattern synonyms as the only way to achieve a "two-way" strict pattern synonym. That is: {{{#!hs pattern MyPair1 x y <- MkPair !x !y where MyPair1 !x !y = MkPair x y }}} Therefore, the fact that you can currently do this: {{{#!hs pattern MyJust a = JustC !a }}} Should be treated as a bug. `JustC !a` makes no sense as an expression, and moreover, it doesn't even give the strictness behavior that you'd expect, as discovered in comment:2. Does that sound agreeable, carter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:27:36 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.f432c691a2cdac298008c493226eb8c1@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed with extra check -- but it should check for the fact that neither is a forall or both are foralls. I don't see a problem in decomposing a dependent application in this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:32:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:32:08 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.244fab9332818945569c8df4c558fb2a@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK: might you do this? Not hard, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:33:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:33:26 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.b89b9665a451c9034e66122be58839ae@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:53:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:53:27 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.195d02d51e487a64023c40cb9bc7b298@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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): Ryan has it right. The syntax is {{{ pattern P x y z = }}} Hence bangs are allowed. For the implicitly-bidirectional case we have to turn the `` into an expression. Currently, that conversion simply discards the bangs, which is the behaviour you are seeing. Silently ignoring the bangs is arguably rather undesirable. (The conversion also silently ignores a `~`, but that's probably correct behaviour.) It would make more sense to do one of these: A. Reject an implicitly-bidirectional pattern with bangs, on the grounds that it's not invertible (like view patterns, say); suggest using an explicitly-bidirectional pattern instead. B. Auto-generate the bang'd definition that Ryan writes above. {{{ MkPair1 !x !y = MkPair x y }}} That is, in the `ImplicitBidirectional` case, if we see `!x` in the pattern, use a `!x`, instead of `x` as the argument pattern of the builder. I think I prefer (B). It's easy to implement: see `mk_match_group` in `TcPatSyn.tcPatSynBuilderBind` . You'd need to alter `tcPatToExpr` to return the banged variables. (Ignore bangs on constructors e.g. `Just !(Just x)`; they are no-ops.) Don't forget to specify all this in the user manual. Volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:53:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:53:57 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.c58a397273536f6f558e1311396b9f55@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Since this ticket was originally opened, SPJ started a [https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html very relevant discussion] on the GHC devs mailing list about a way to salvage `ImpredicativeTypes`. It wouldn't make the original program in this ticket typecheck again, but it would provide a way to possibly suggest a workaround in error messages. To quote SPJ: > When you have `-XImpredicativeTypes` > > * You can write a polytype in a visible type argument; eg. `f @(forall a. a->a)` > > * You can write a polytype as an argument of a type in a signature e.g. `f :: [forall a. a->a] -> Int` > > And that’s all. A unification variable STILL CANNOT be unified with a polytype. The only way you can call a polymorphic function at a polytype is to use Visible Type Application. > > So using impredicative types might be tiresome. E.g. > > {{{#!hs > type SID = forall a. a->a > > > > xs :: [forall a. a->a] > > xs = (:) @SID id ( (:) @SID id ([] @ SID)) > }}} > > In short, if you call a function at a polytype, you must use VTA. Simple, easy, predictable; and doubtless annoying. But possible. However, this should undoubtedly go through a GHC proposal. At the very least, it's unclear to me whether SPJ's intention was to require actually enabling `-XImpredicativeTypes` in order to visibly apply a polytype (the title of the GHC devs discussion, "Getting rid of `-XImpredicativeTypes`", makes me think "no", but the actual contents of the discussion that I quoted would suggest "yes"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:54:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:54:12 -0000 Subject: [GHC] #14160: Type inference breaking change in GHC 8.0.2 In-Reply-To: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> References: <051.4f5a95caec5b96c8a806a90e2349e7b5@haskell.org> Message-ID: <066.fd71cb9d0c60a1e2f5f3746e5deb9baf@haskell.org> #14160: Type inference breaking change in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: wontfix | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11319 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix * related: => #11319 Comment: I was just about to open a new ticket with a title like "Figure out how to salvage `ImpredicativeTypes`", but then I discovered #11319, with the very apt title "`ImpredicativeTypes` even more broken than usual". I think this is a good place for this discussion (especially since it talks about `TypeApplications`), so I'll move the discussion there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:57:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:57:36 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.86b730edc61dd784fde5a76b135d8f32@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Could we fix one case this with a well-placed zonk? More broadly (re: could this happen elsewhere?) I've grown increasingly uncomfortable with the way GHC handles tyvars and zonking. When the type- checker fills in a metavariable, it then assumes that the metavar and its new value are equal. Except, of course, pure code can (and will, to our dismay) spot the difference. So, we could make `tc` versions of various type-manipulation functions (we indeed already do) and make them monadic, looking through metavars (this bit is new). That's disappointing, somehow. But I don't really see a better option. If we did this -- and did it reliably -- I think we could remove `zonkTcType` and friends (keeping only `zonkTcTypeToType` and friends). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 13:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 13:59:51 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.8e8be20a8d40eb1014f1279f061872fb@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed about the proposal. Let's hash out the details there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:00:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:00:32 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.31fa34e0d9c346225e0650e57758731d@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * milestone: => 8.4.1 Comment: The only reason I don't favor (B) is because it's not always clear how you'd translate bang patterns on the RHS of an implicitly bidirectional pattern synonym to bang patterns for the builder arguments. For example, how would this be desugared? {{{#!hs pattern Foo a = Just !(Just a) }}} The only sensible thing I could envision here would be to silently ignore the bang pattern, but that makes me just as uncomfortable as it does you. I'd be willing to implement option (A). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:04:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:04:59 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.b17caa9f1e165c55d7b53f95fe64c168@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: RyanGlScott => (none) Comment: Alas, I bit off way more than I could chew with this ticket. It'll take someone more familiar with the rocket science that powers the renamer to fix this, I think. Unassigning myself as the owner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:09:17 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.ce9e03596ff2cd3045de2135fd2a7f88@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Could we fix one case this with a well-placed zonk? I suppose we could always zonk before calling `typeKind`. But I am deeply averse to doing this. * The constraint solver does zonking on the fly, as part of canonicalisation. That is simple and nice. I don't think we should ''ever'' call zonking when we are solving constraints. * I think the constraint solver indeed obeys the invariant that we never constructor an ill-kinded type, provided you ''don't'' zonk it! But, as remarked above, `tcDataConPat` does form an ill-kinded type. I think right solution is not do to so, which isn't difficult. What I'm upset about is that it's hard to be sure when we have nailed every case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:10:15 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.5651806cde6c793f105a1d1b79caf3b8@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is in my area. I'll take a look in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:13:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:13:54 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.ae817529a0a15e3a2762b5820a08c244@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Would an `ASSERT` in `mkAppTy` do it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:56:41 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.42b4b7ba67a0d310adf9f24144c7d30b@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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): As I say, bang on data constructors are always no-ops. They are ignored in patterns too! So it's fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:57:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:57:21 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.439c1a671d8ba430d81aba438d9cf66d@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => simonpj Comment: I'm 99% through this. I'll commit shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 14:57:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 14:57:39 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.2327e84b1cb62c062a0fb6c690156b6b@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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 RyanGlScott): That was perhaps a poor example. Here's an example that is less clear: {{{#!hs pattern Foo f a = Just !(f a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 15:01:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 15:01:43 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.6d8c290f2fd6a384284417a85a86347b@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): An assert in every smart type constuctor `mkTyConApp`, `mkFunTy` etc, that checked that the type was well kinded, yes. `mkAppTy` is just one example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 16:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 16:33:05 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.1aa50b712976bf3ae6582c74d21ab74a@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I also noticed this paper ([https://www.microsoft.com/en-us/research/wp- content/uploads/2017/07/impredicative-Jul17.pdf Guarded impredicative polymorphism]) from Simon's website as "in submission", how does it relate? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 16:41:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 16:41:06 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.47337280f56c58c226183690ebbed37f@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But the actual error is somewhere in the unfolding wrapper for `SSubNil`, which is injected by `CorePrep` and looks like this {{{ SSubNil :: forall a (ys :: Maybe a) (x :: SubList a ys). ((ys :: Maybe a) ~# ('Nothing a :: Maybe a), (x :: SubList a ys) ~# ('SubNil a :: SubList a ('Nothing a))) => R:SingSubListx a ys x [GblId[DataCon], Arity=2, Caf=NoCafRefs, Str=m, Unf=OtherCon []] SSubNil = \ (@ a_aSK) (@ (ys_aRV :: Maybe a_aSK)) (@ (x_aRW :: SubList a_aSK ys_aRV)) (eta_B2 :: (ys_aRV :: Maybe a_aSK) ~# ('Nothing a_aSK :: Maybe a_aSK)) (eta_B1 :: (x_aRW :: SubList a_aSK ys_aRV) ~# ('SubNil a_aSK :: SubList a_aSK ('Nothing a_aSK))) -> SSubNil @ a_aSK @ ys_aRV @ x_aRW @~ (eta_B2 :: (ys_aRV :: Maybe a_aSK) ~# ('Nothing a_aSK :: Maybe a_aSK)) @~ (eta_B1 :: (x_aRW :: SubList a_aSK ys_aRV) ~# ('SubNil a_aSK :: SubList a_aSK ('Nothing a_aSK))) }}} Lint says {{{ *** Core Lint errors : in result of CorePrep *** : warning: In the type ‘forall a (ys :: Maybe a) (x :: SubList a ys). ((ys :: Maybe a) ~# ('Nothing a :: Maybe a), (x :: SubList a ys) ~# ('SubNil a :: SubList a ('Nothing a))) => R:SingSubListx a ys x’ Kind application error in type ‘SubList a_aSK ys_aRV’ Function kind = forall {a}. Maybe a -> * Arg kinds = [(a_aSK, *), (ys_aRV, Maybe a_aSv)] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:15:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:15:10 -0000 Subject: [GHC] #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) In-Reply-To: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> References: <051.77c813c67b1afa92b231b6a3ca707f7d@haskell.org> Message-ID: <066.5f5b83c966109874309e307d59a8eeef@haskell.org> #14157: Flipping (give :: a -> (Given a => r) -> r) has type (r -> a -> r) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I was surprised to see the constraint vanish completely! There are clearly gaps in my understanding of the type system but the reasons given make sense, my deepest thanks to you both for taking the time to respond to my tickets -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:37:24 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.36fdd0538c39fce4b8955e1bc04aa830@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: patch Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:38:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:38:53 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.3637e36d75b3a12ab87662761bc2ddc3@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: patch Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:40:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:40:57 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.3b665d07643976be999d2e30b0f92d4a@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: patch Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:6 h4ck3rm1k3]: > Noob question, I cannot see this branch on the git://git.haskell.org/ghc.git and for some reason I cannot fetch from the phab : > > git fetch https://phabricator.haskell.org/diffusion/GHC/glasgow-haskell- compiler.git > fatal: unable to access 'https://phabricator.haskell.org/diffusion/GHC /glasgow-haskell-compiler.git/': The requested URL returned error: 500 The branch isn't on git.haskell.org because I haven't put it there. I suppose I could if you like. As for getting branches from Phabricator.... um ... I'm not the best at that. I think you can use `arc patch` or something, maybe? bgamari could say for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:47:53 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.5cfb597a33ea011c93bd64e18d5df96a@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: patch Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sadly Phabricator Differentials aren't automatically branches. dfeuer will need to push the branch to git.haskell.org in order for you to check it out with git. Alternatively you can use arcanist to apply the differential (e.g. `arc patch D3894`) or you can download the patch from Phabricator and apply it to your tree manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:53:17 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo Message-ID: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2). The compilation runs smooth, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with a stack overflow error. I tried to find a minimal example that causes this behavior: {{{ #!/usr/bin/env stack -- stack --resolver nightly-2017-08-25 script {-# LANGUAGE ApplicativeDo #-} x = do (a, _) <- undefined (b, _) <- undefined (c, _) <- undefined undefined main = undefined }}} It only happens with at least 3 of these pattern matches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 17:53:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 17:53: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.45ccc7c063684a3a6e709c4f0c28c222@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.4.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 lippling): Ok, I created https://ghc.haskell.org/trac/ghc/ticket/14163#ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 18:00:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 18:00:50 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.0907ed13619806077bd0487438d04642@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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 RyanGlScott): They might be ignored for data constructors, yes. But what about pattern synonyms? For instance, we have that: {{{ λ> pattern Id a = a λ> let f (Id _) = "foo" λ> f undefined "foo" λ> let g !(Id _) = "bar" λ> g undefined "*** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at :19:3 in interactive:Ghci9 }}} That is to say, bang patterns aren't no-ops for //every// conlike, as they matter in the presence of pattern synonyms. This awkwardly melds with implicitly bidirectional pattern synonyms, since if you define this: {{{ λ> pattern Foo a = Just !(Id a) λ> case Foo undefined of Just _ -> "wat" "wat" λ> case Just undefined of Foo _ -> "wat" "*** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at :22:11 in interactive:Ghci11 }}} Notice that the bang pattern doesn't kick in when `Foo` is used as an expression, only as a pattern. In order to make a `Foo` expression strict as a pattern, you'd have to dig underneath the `Id` pattern synonym to figure out whether //its// bindings are strict or not. All of this sounds terribly fiddly in contrast to option (A), which is simple to describe, implement, and even gives nice error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 18:15:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 18:15:57 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.79da6986fe1a229012d8610084904fc1@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lippling: Old description: > I tried to compile one of our server applications with 8.2.1 (which > compiles fine with 8.0.2). > > The compilation runs smooth, but when it reaches a specific file, the RAM > usage goes up to > 20GB pretty fast on my 16GB machine and the GHC > process gets terminated with a stack overflow error. > > I tried to find a minimal example that causes this behavior: > > {{{ > #!/usr/bin/env stack > -- stack --resolver nightly-2017-08-25 script > > {-# LANGUAGE ApplicativeDo #-} > > x = do > (a, _) <- undefined > (b, _) <- undefined > (c, _) <- undefined > undefined > > main = undefined > }}} > > It only happens with at least 3 of these pattern matches. New description: I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2). The compilation runs smoothly, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with a stack overflow error. I tried to find a minimal example that causes this behavior: {{{ #!/usr/bin/env stack -- stack --resolver nightly-2017-08-25 script {-# LANGUAGE ApplicativeDo #-} x = do (a, _) <- undefined (b, _) <- undefined (c, _) <- undefined undefined main = undefined }}} It only happens with at least 3 of these pattern matches. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 19:06:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 19:06:39 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency Message-ID: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeOperators, DataKinds, PolyKinds, KindSignatures, TypeInType, GADTs, TypeFamilyDependencies #-} import Data.Kind type Cat a = a -> a -> Type data SubList :: Cat [a] where SubNil :: SubList '[] '[] Keep :: SubList xs ys -> SubList (x:xs) (x:ys) Drop :: SubList xs ys -> SubList xs (x:ys) type family UpdateWith (ys'::[a]) (xs::[a]) (pf::SubList ys xs) = (res :: [a]) | res -> pf ys' xs where UpdateWith '[] '[] SubNil = '[] UpdateWith (y:ys) '[] SubNil = y:ys -- UpdateWith '[] (_:_) (Keep _) = '[] UpdateWith (y:ys) (_:xs) (Keep rest) = y:UpdateWith ys xs rest -- UpdateWith ys (x:xs) (Drop rest) = x:UpdateWith ys xs rest }}} seems to loop forever on the "`Renamer/typechecker`" {{{ $ ghci -ignore-dot-ghci -v /tmp/u.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.3.20170605, stage 2 booted by GHC version 8.0.2 [...] *** Parser [Main]: !!! Parser [Main]: finished in 1.31 milliseconds, allocated 0.651 megabytes *** Renamer/typechecker [Main]: [hangs] }}} while {{{#!hs type family UpdateWith (ys'::[a]) (xs::[a]) (pf::SubList ys xs) = (res :: [a]) | res -> pf ys' xs where UpdateWith '[] '[] SubNil = '[] UpdateWith (y:ys) '[] SubNil = y:ys UpdateWith '[] (_:_) (Keep _) = '[] }}} immediately gives {{{ $ ghc -ignore-dot-ghci /tmp/u.hs [1 of 1] Compiling Main ( /tmp/u.hs, /tmp/u.o ) /tmp/u.hs:14:3: error: • Type family equations violate injectivity annotation: UpdateWith '[] '[] 'SubNil = '[] -- Defined at /tmp/u.hs:14:3 forall a (xs :: [a]) (_1 :: [a]) (_2 :: a) (_3 :: SubList xs _1). UpdateWith '[] (_2 : _1) ('Keep _3) = '[] -- Defined at /tmp/u.hs:16:3 • In the equations for closed type family ‘UpdateWith’ In the type family declaration for ‘UpdateWith’ | 14 | UpdateWith '[] '[] SubNil = '[] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /tmp/u.hs:16:3: error: • Type family equation violates injectivity annotation. Type and kind variables ‘_2’, ‘_1’, ‘xs’, ‘_3’ cannot be inferred from the right-hand side. Use -fprint-explicit-kinds to see the kind arguments In the type family equation: forall a (xs :: [a]) (_1 :: [a]) (_2 :: a) (_3 :: SubList xs _1). UpdateWith '[] (_2 : _1) ('Keep _3) = '[] -- Defined at /tmp/u.hs:16:3 • In the equations for closed type family ‘UpdateWith’ In the type family declaration for ‘UpdateWith’ | 16 | UpdateWith '[] (_:_) (Keep _) = '[] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 19:21:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 19:21:11 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.6cde3dc9f8313a0064bea7b237861c44@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): (Does `UpdateWith` in any way (including with generalized injectivity #10832) makes sense as injective) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 19:55:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 19:55:34 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.663cb34b1a9b7737f972fbbfdaa26076@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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 carter): so what i'm sensing is the point that normal / "strict" data types are only strict on construction, but lazy on matching (except perhaps when dealing with unpacked/unboxed style internal tricks eg mapping Int to Int# etc). In contrast, we have here a way that can express lazy construction and strict matching? am i missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 28 21:04:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Aug 2017 21:04:41 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.c18c7a7fe02d6a420af6b24ad61b1747@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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): > But what about pattern synonyms? That's an excellent point, one that I had not considered. The right thing to do would probably be to `seq` on the sub-pattern thus {{{ pattern P x = Just !(Id x) }}} would give rise to a builder thus {{{ P x = let !a = Id x in Just a }}} In short, when converting from pattern to expression, let!-bind the expressions gotten from converting each banged sub-pattern. But now I grant you that the cost/benefit ratio is less attractive. I'm happy with A. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 01:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 01:29:54 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.86d5c8062b26da9c8e313a66dc9470d0@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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): Phab:D3896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3896 Comment: I've implemented (A) in Phab:D3896. Replying to [comment:10 carter]: > so what i'm sensing is the point that > > normal / "strict" data types are only strict on construction, but lazy on matching (except perhaps when dealing with unpacked/unboxed style internal tricks eg mapping Int to Int# etc). > > In contrast, we have here a way that can express lazy construction and strict matching? > > am i missing something? I'd summarize the point by saying that if you were to hypothetically allow an implicitly bidirectional pattern synonym with a bang pattern in the RHS, you'd want both the pattern and the builder expression to be strict. However, in practice GHC was making the pattern strict, but not the builder. We pondered whether it would be possible to desugar a builder that figured out the right strictness, but this turns out to be an awkward thing to do in the presence of other pattern synonyms in the RHS. It's much easier to simply disallow bang patterns in the RHS altogether, since this avoids the need to explain away a special syntactic rule that only applies for expressions in implicitly bidirectional pattern synonyms. (In Phab:D3896, I've tailored the error message so that if you do try typing something like `data StrictJust a = Just !a`, it recommends using an explicitly bidirectional pattern synonym instead.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 02:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 02:35:57 -0000 Subject: [GHC] #14165: Investigate regressions from simplifier refactor Message-ID: <045.a0f71c607720cfbc97de5b3a50b2a13e@haskell.org> #14165: Investigate regressions from simplifier refactor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Commit 33452dfc6cf891b59d63fa9fe138b18cbce4df81 (Refactor the Mighty Simplifier) caused test suite regressions under 64-bit Linux and OSX (but not 32-bit Linux or Windows). See the [https://phabricator.haskell.org/B17259 build results]. Under 64-bit Linux: {{{ max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 16679176 +/-15% Lower bound T1969(normal) max_bytes_used: 14177299 Upper bound T1969(normal) max_bytes_used: 19181053 Actual T1969(normal) max_bytes_used: 19199872 Deviation T1969(normal) max_bytes_used: 15.1 % *** unexpected stat test failure for T1969(normal) bytes allocated value is too high: Expected T12150(optasm) bytes allocated: 70773000 +/-5% Lower bound T12150(optasm) bytes allocated: 67234350 Upper bound T12150(optasm) bytes allocated: 74311650 Actual T12150(optasm) bytes allocated: 74358208 Deviation T12150(optasm) bytes allocated: 5.1 % }}} Under 64-bit OSX: {{{ bytes allocated value is too high: Expected T12150(optasm) bytes allocated: 70773000 +/-5% Lower bound T12150(optasm) bytes allocated: 67234350 Upper bound T12150(optasm) bytes allocated: 74311650 Actual T12150(optasm) bytes allocated: 74503808 Deviation T12150(optasm) bytes allocated: 5.3 % *** unexpected stat test failure for T12150(optasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 02:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 02:57:32 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.af8557cb8d3c471cb6371766ec190b7e@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I traced this down to a diverging call to [http://git.haskell.org/ghc.git/blob/682e8e6e01cd9c96378692656649094ad44c35a7:/compiler/types/FamInstEnv.hs#l576 tcUnifyTyWithTFs] in `FamInstEnvs.injectiveBranches`. I don't know //why// it's diverging, but I do know that its arguments `rhs1` and `rhs2` are (according to `pprTrace`): {{{ (rhs1) y_a1tT : UpdateWith ys2_a1tU xs_a1tV rest_a1tW (rhs2) y_a1tR : ys_a1tS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 03:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 03:31:10 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.c2d2abea1a535776a64cc31c78473bc4@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: patch Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"29da01e0a023eea4bbbfd69dd5d854db721233e6/ghc" 29da01e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29da01e0a023eea4bbbfd69dd5d854db721233e6" Make parsed AST dump output lazily Previously, `showAstData` produced a `String`. That `String` would then be converted to a `Doc` using `text` to implement `-ddump-parsed-ast`. But rendering `text` calculates the length of the `String` before doing anything else. Since the AST can be very large, this was bad: the whole dump string (potentially hundreds of millions of `Char`s) was accumulated in memory. Now, `showAstData` produces a `Doc` directly, which seems to work a lot better. As an extra bonus, the code is simpler and cleaner. The formatting has changed a bit, as the previous ad hoc approach didn't really match the pretty printer too well. If someone cares enough to request adjustments, we can surely make them. Reviewers: austin, bgamari, mpickering, alanz Reviewed By: bgamari Subscribers: mpickering, rwbarton, thomie GHC Trac Issues: #14161 Differential Revision: https://phabricator.haskell.org/D3894 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 03:52:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 03:52:19 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.e39b0de6772e020669ba859efc4cd94b@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: merge Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge Comment: I suspect this is small enough to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 08:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 08:37:24 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.3d3fb7dd479bfec5bed312e0c2974316@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4455c86d1635bfb846e750b21dda36dcee028b5e/ghc" 4455c86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4455c86d1635bfb846e750b21dda36dcee028b5e" Use a well-kinded substitution to instantiate In tcDataConPat we were creating an ill-kinded substitution -- or at least one that is well kinded only after you have solved other equalities. THat led to a crash, because the instantiated data con type was ill-kinded. This patch guarantees that the instantiating substitution is well-kinded. Fixed Trac #14154 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 08:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 08:37:24 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.c65ce89013acdc45fd8ccfdacfd64863@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0257dacf228024d0cc6ba247c707130637a25580/ghc" 0257dacf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0257dacf228024d0cc6ba247c707130637a25580" Refactor bindHsQTyVars and friends This work was triggered by Trac #13738, which revealed to me that the code RnTypes.bindHsQTyVars and bindLHsTyVarBndrs was a huge tangled mess -- and outright wrong on occasion as the ticket showed. The big problem was that bindLHsTyVarBndrs (which is invoked at every HsForAll, including nested higher rank ones) was attempting to bind implicit kind variables, which it has absolutely no busineess doing. Imlicit kind quantification is done at the outside only, in fact precisely where we have HsImplicitBndrs or LHsQTyVars (which also has implicit binders). Achieving this move was surprisingly hard, because more and more barnacles had accreted aroud the original mistake. It's much much better now. Summary of changes. Almost all the action is in RnTypes. * Implicit kind variables are bound only by - By bindHsQTyVars, which deals with LHsQTyVars - By rnImplicitBndrs, which deals with HsImplicitBndrs * bindLHsTyVarBndrs, and bindLHsTyVarBndr are radically simplified. They simply does far less, and have lots their forest of incomprehensible accumulating parameters. (To be fair, some of the code in bindLHsTyVarBndrs just moved to bindHsQTyVars, but in much more perspicuous form.) * The code that checks if a variable appears in both a kind and a type (triggering RnTypes.mixedVarsErr) was bizarre. E.g. we had this in RnTypes.extract_hs_tv_bndrs ; check_for_mixed_vars bndr_kvs acc_tvs ; check_for_mixed_vars bndr_kvs body_tvs ; check_for_mixed_vars body_tvs acc_kvs ; check_for_mixed_vars body_kvs acc_tvs ; check_for_mixed_vars locals body_kvs I cleaned all this up; now we check for mixed use at binding sites only. * Checks for "Variable used as a kind before being bound", like data T (a :: k) k = rhs now just show up straightforwardly as "k is not in scope". See Note [Kind variable ordering] * There are some knock-on simplifications in RnSource. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 08:53:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 08:53:33 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.e36d55ed621fccaf183ec733b2aef0a4@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14154 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T14154 * milestone: => 8.2.2 Comment: Probably small enough to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 08:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 08:54:44 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.973c91822dd9349ed5e8332bc83130cf@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13738 Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T13738 * status: patch => closed * resolution: => fixed Comment: OK done! I'd be happy if Richard and/or Ryan wanted to review the changes, but I'm very content with them. A useful step forward. Oh, and it fixes the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 10:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 10:16:29 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.f1a571084a0ff9ed1849c78be72f742d@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I can't seem to be able to reproduce this though... Actually I wonder, does `ghc --interactive` have the same behavior? So don't go through the `ghci.exe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 10:21:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 10:21:23 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.b4e07e8b0cc2a6fd028aa3666bdc745c@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ApplicativeDo * owner: (none) => simonmar Comment: OK Simon M is the expert here. But I did find that if I add the following `traceRn` in `rearrangeForApplicativeDo`: {{{ rearrangeForApplicativeDo ctxt stmts0 = do optimal_ado <- goptM Opt_OptimalApplicativeDo let stmt_tree | optimal_ado = mkStmtTreeOptimal stmts | otherwise = mkStmtTreeHeuristic stmts traceRn "rearrangeForADo" (ppr stmt_tree) <------------------- NEW return_name <- lookupSyntaxName' returnMName pure_name <- lookupSyntaxName' pureAName }}} then I get this output {{{ rearrangeForADo (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind (StmtTreeBind }}} That is, it seems that `mkStmtTreeHeuristic`goes into a loop. If you use `-foptimal-applicative-do` it works fine! Over to you, Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 10:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 10:40:26 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.c396e58988350e960166656f2e65b2c2@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): So the workarounds are: - Disable ApplicativeDo -OR- - Enable the `-foptimal-applicative-do` flag and have longer compile times (O(n^2) vs. O(n^3)) -OR- - Rearrange the code so that ApplicativeDo doesn't "trigger" Am I right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 11:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 11:03:09 -0000 Subject: [GHC] #14166: Typo Fix `necssary` Message-ID: <049.5d630cac9b72315235a0b59455deec53@haskell.org> #14166: Typo Fix `necssary` -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- https://github.com/ghc/ghc/pull/72 diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 1bde776..f75cc2c 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is used as follows https://phabricator.haskell.org/rGHC499e43824bda967546ebf95ee33ec1f84a114a7c * ParPat and HsParTy are pretty printed as '( .. )' regardless of whether or - not they are strictly necssary. This should be addressed when #13238 is + not they are strictly necessary. This should be addressed when #13238 is completed, to be treated the same as HsPar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 11:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 11:03:39 -0000 Subject: [GHC] #14166: Typo Fix `necssary` In-Reply-To: <049.5d630cac9b72315235a0b59455deec53@haskell.org> References: <049.5d630cac9b72315235a0b59455deec53@haskell.org> Message-ID: <064.729d6a1931545ce8138908606ced3c2e@haskell.org> #14166: Typo Fix `necssary` -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Description changed by h4ck3rm1k3: Old description: > https://github.com/ghc/ghc/pull/72 > > diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs > index 1bde776..f75cc2c 100644 > --- a/compiler/hsSyn/HsExpr.hs > +++ b/compiler/hsSyn/HsExpr.hs > @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is > used as follows > https://phabricator.haskell.org/rGHC499e43824bda967546ebf95ee33ec1f84a114a7c > > * ParPat and HsParTy are pretty printed as '( .. )' regardless of > whether or > - not they are strictly necssary. This should be addressed when #13238 > is > + not they are strictly necessary. This should be addressed when > #13238 is > > completed, to be treated the same as HsPar. New description: https://github.com/ghc/ghc/pull/72 diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 1bde776..f75cc2c 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is used as follows * ParPat and HsParTy are pretty printed as '( .. )' regardless of whether or - not they are strictly necssary. This should be addressed when #13238 is + not they are strictly necessary. This should be addressed when #13238 is completed, to be treated the same as HsPar. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 11:04:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 11:04:24 -0000 Subject: [GHC] #14166: Typo Fix `necssary` In-Reply-To: <049.5d630cac9b72315235a0b59455deec53@haskell.org> References: <049.5d630cac9b72315235a0b59455deec53@haskell.org> Message-ID: <064.309e5d29ace2371f284cdfb864367460@haskell.org> #14166: Typo Fix `necssary` -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Description changed by h4ck3rm1k3: Old description: > https://github.com/ghc/ghc/pull/72 > > diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs > index 1bde776..f75cc2c 100644 > --- a/compiler/hsSyn/HsExpr.hs > +++ b/compiler/hsSyn/HsExpr.hs > @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is > used as follows > > * ParPat and HsParTy are pretty printed as '( .. )' regardless of > whether or > - not they are strictly necssary. This should be addressed when #13238 > is > + not they are strictly necessary. This should be addressed when > #13238 is > > completed, to be treated the same as HsPar. New description: created a pull request here https://github.com/ghc/ghc/pull/72 {{{ diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 1bde776..f75cc2c 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is used as follows * ParPat and HsParTy are pretty printed as '( .. )' regardless of whether or - not they are strictly necssary. This should be addressed when #13238 is + not they are strictly necessary. This should be addressed when #13238 is completed, to be treated the same as HsPar. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:15:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:15:10 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.68f65c99033225744ea1fea3b3c10336@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, I can no longer reproduce this on GHC HEAD. I wonder what fixed it? Time to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:18:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:18:18 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.d30fd67ddd2712774e59d9721e788017@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I noticed that too. I think it's a consequence of one of my recent commits: I suspect {{{ commit a6c448b403dbe8720178ca82100f34baedb1f47e Author: Simon Peyton Jones Date: Mon Aug 28 17:33:59 2017 +0100 Small refactor of getRuntimeRep }}} If you could bisect that would save me time. Even if it is, I'd like to understand WHY it fixed it! Which I don't right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:33:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:33:46 -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.d495e0e40743c5f1436298a49f9fc695@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > I agree with Simon that floating these things out and keeping them out feels “wrong” in the sense that it fights against the usual working of the simplifier. Well, now I understand better, I do quite like this approach. I'm not ready to give it up yet! * `preInlineUnconditionally`. Yes `caonInlineInLam` is true, but `int_cxt` (short for "interesting context") is probably false. * `completeCall`: I think we may be saying "never inline a join point that appears on the RHS of a recursive join point". We can make that happen by giving its unfolding an `UnfoldingGuidance` of `UnfNever`. We can spot that it apperas on the RHS of a recursive join point because its occ-info will have `occ_in_lam` = True. * `postInlineUnconditionally`. As the comments say, the main goal here is to solve this {{{ -- let x = f y in -- case v of -- True -> case x of ... -- False -> case x of ... }}} Here we want to inline `x`, otherwise it allocates a thunk. But join points do not allocate thunks; perhaps we can simply not do `postInlineUnconditionally` on the `OneOcc` branch? And in fact giving it an `UnfoldingGuidance` of `UnfNever` will also stop it inlining. NB: right at the end (in `CorePrep` perhaps) we may want to inline them after all, just to reduce clutter and jumps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:38:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:38:33 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.306ea5f5db9e2fbd9d3f046c087b2f14@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, `Small refactor of getRuntimeRep` is the first commit in which the program above works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:50:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:50:28 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.e1a19c5f7aafce169823e003a4c80528@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.2 Comment: Hmm, perhaps we should consider cherry-picking this in that case. It looks like it will apply pretty easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 13:56:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 13:56:51 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.1d0c978ab18e334fc080d98d0646d6da@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, good eye. Indeed, this problem does //not// happen with `ghc.exe --interactive`, only with `ghci.exe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:12:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:12:14 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.62924ad4fdcbb8955591b8c1c7194a6f@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies 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: => InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:17:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:17:00 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.b600d3e8e94e9b39ae1956173eac0e5f@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Humorously enough, the panic is now different on GHC HEAD (likely due to commit a6c448b403dbe8720178ca82100f34baedb1f47e, `Small refactor of getRuntimeRep`): {{{ $ ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170828: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170828 for x86_64-unknown-linux): getRuntimeRep (f_a5yC[sk:2] |> Sym (Sym (D:R:Funk1:->k2[0] _N _N) ; D:R:Funk1:->k2[0] _N <*>_N)) a_a5yD[sk:2] :: k2_a5n3 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1982:18 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:25:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:25:54 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.17712f3dd67b713066744f7b394637c1@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): I am able to reproduce this locally. Here is a small reproducer, {{{#!c #include #include #include #include #include #include #include int main () { int fd = open("libraries/bootstrapping.conf/package.cache.lock", O_RDONLY|O_NOCTTY|O_NONBLOCK); int res; struct stat stat; res = fstat(fd, &stat); printf("stat: %s\n", strerror(errno)); res = flock(fd, LOCK_EX); printf("flock: %s\n", strerror(errno)); res = flock(fd, LOCK_UN); printf("funlock: %s\n", strerror(errno)); close(fd); return 0; } }}} When run in an NFS-mounted GHC tree with an existing lockfile this will fail with, {{{ $ gcc test.c && ./a.out stat: Success flock: Bad file descriptor funlock: Bad file descriptor }}} Strangely if one changes `O_RDONLY` to `O_RDWR` the failure becomes, {{{ $ gcc test.c && ./a.out stat: Success flock: No locks available funlock: No locks available }}} So I think this may be in part due to the read-only nature of the fd, but there may be more at play. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:33:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:33:29 -0000 Subject: [GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't Message-ID: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: GADTs, | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from Phab:D3880.) There are at least a couple of points in the GHC codebase where poor decisions are made regarding whether to depict a datatype using H98 syntax or GADT syntax. In particular: 1. When reifying a datatype in Template Haskell, some complicated heuristics are used to determine whether a datatype is reified with `(Rec)GadtC` or not (see `Note [Reifying GADT data constructors]` in `TcSplice` for the horrifying details). But these heuristics are far from perfect, as they will cause some vanilla datatypes to be reified as GADTs (e.g., `data T a = (a ~ Int) => MkT`). 2. When pretty-printing a datatype (for instance, via the `:info` command in GHCi), GHC also chooses to sometimes depict vanilla datatypes as GADTs. For instance: {{{ λ> :set -XExistentialQuantification λ> data Foo a = Show a => Foo λ> :i Foo type role Foo nominal data Foo a where Foo :: Show a => Foo a }}} `Foo` is depicted as a GADT, despite the fact that we didn't use GADT syntax. There might be other places in the code that exhibit these symptoms too—we should take a closer look. I use the phrase "poor decisions" above since GHC really does have the right info it needs to make the correct decisions. That info is in the form of the `isGadtSyntaxTyCon`, which conveniently recalls whether a datatype was declared with GADT syntax or not. With this, we should be able to eliminate the flawed heuristics that GHC is currently using and accurately depict datatypes the way users wrote them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:47:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:47:57 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.4052b54f9242c739303ee248edab2e05@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * Attachment "test.c" added. An end-to-end testcase -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:48:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:48:09 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.c988d496a29b253efb110f4e4d42e9b9@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Here is a standalone test. I have confirmed that this runs on my local filesystem, yet not on my NFS mount (where both the server and client are running `statd`, `rpcbind`, and `portmapper`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 14:56:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 14:56:13 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.9be9aed56660ba6665dea18c9cc11046@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Ahh, the issue appears to be that NFS is more strict about the privileges necessary to take an exclusive (`LOCK_EX`) `flock`. Namely, you need write access. If you only have read access to a file then you can only take a `LOCK_SH` lock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 15:01:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 15:01:37 -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.bf72690b019c80f11004c2f19b85409e@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > I do quite like this approach. I'm not ready to give it up yet! I like this game of bad-cop/good-cop with switching roles. Certainly a productive way of investigating an issue :-) * `preInlineUnconditionally`: Well, `int_cxt` certainly is `True` – otherwise `int_cxt && canInlineInLam rhs` would be `False` and inlining would not happen. Are you saying that it should be made `False`? * `completeCall`: Let me try to make sure I understand the reasoning: Normally a join point will not have `occ_in_lam`, because if it would occur under a “normal” lambda, it wouldn’t be a tail-call. The exception are the lambdas on the RHS of a join points, as these are ignored when calculating `occ_in_lam`. But there is an exception to that: Inside a recursive join point we do set `occ_in_lam`. So the occurrence analyzer should detect this? I’ll try. > NB: right at the end (in CorePrep perhaps) we may want to inline them after all, just to reduce clutter and jumps. Right, I keep that in the back of my mind, but first I need it to actually _not_ inline :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 15:14:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 15:14:46 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed Message-ID: <044.4f270678bb008a7a39539de06752d80f@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed -------------------------------------+------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- I use the ghc-8.2.1 in Windows. When install math-functions, ghc crash. The following is the output. {{{ λ stack install math-functions math-functions-0.2.1.0: configure math-functions-0.2.1.0: build -- While building package math-functions-0.2.1.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 255 Logs have been written to: A:\Glob\.stack-work\logs\math- functions-0.2.1.0.log Configuring math-functions-0.2.1.0... Preprocessing library for math-functions-0.2.1.0.. Building library for math-functions-0.2.1.0.. [ 1 of 10] Compiling Numeric.MathFunctions.Comparison ( Numeric\MathFunctions\Comparison.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Comparison.o ) [ 2 of 10] Compiling Numeric.MathFunctions.Constants ( Numeric\MathFunctions\Constants.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Constants.o ) [ 3 of 10] Compiling Numeric.Polynomial ( Numeric\Polynomial.hs, .stack-work\dist\e53504d9\build\Numeric\Polynomial.o ) [ 4 of 10] Compiling Numeric.Polynomial.Chebyshev ( Numeric\Polynomial\Chebyshev.hs, .stack- work\dist\e53504d9\build\Numeric\Polynomial\Chebyshev.o ) [ 5 of 10] Compiling Numeric.RootFinding ( Numeric\RootFinding.hs, .stack-work\dist\e53504d9\build\Numeric\RootFinding.o ) [ 6 of 10] Compiling Numeric.Series ( Numeric\Series.hs, .stack- work\dist\e53504d9\build\Numeric\Series.o ) [ 7 of 10] Compiling Numeric.SpecFunctions.Internal ( Numeric\SpecFunctions\Internal.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Internal.o ) C:\Users\qinka\AppData\Local\Temp\stack12716\math- functions-0.2.1.0\Numeric\SpecFunctions\Internal.hs:24:1: warning: [-Wunused-imports] The import of 鈥榚xpm1鈥?from module 鈥楪HC.Float鈥?is redundant | 24 | import GHC.Float (log1p,expm1) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 8 of 10] Compiling Numeric.SpecFunctions.Extra ( Numeric\SpecFunctions\Extra.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Extra.o ) [ 9 of 10] Compiling Numeric.SpecFunctions ( Numeric\SpecFunctions.hs, .stack-work\dist\e53504d9\build\Numeric\SpecFunctions.o ) [10 of 10] Compiling Numeric.Sum ( Numeric\Sum.hs, .stack- work\dist\e53504d9\build\Numeric\Sum.o ) ghc.EXE: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 15:41:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 15:41:28 -0000 Subject: [GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't In-Reply-To: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> References: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> Message-ID: <065.4ba55eacd90aaf5fcff3e16a03c1f50a@haskell.org> #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GADTs, | TemplateHaskell Operating System: 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): > GHC really does have the right info it needs to make the correct decisions. Yes indeed. Go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 15:57:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 15:57:11 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.7a5cf413e45593d6c2aa85024bb7969c@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.2.2 Old description: > I tried to compile one of our server applications with 8.2.1 (which > compiles fine with 8.0.2). > > The compilation runs smoothly, but when it reaches a specific file, the > RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC > process gets terminated with a stack overflow error. > > I tried to find a minimal example that causes this behavior: > > {{{ > #!/usr/bin/env stack > -- stack --resolver nightly-2017-08-25 script > > {-# LANGUAGE ApplicativeDo #-} > > x = do > (a, _) <- undefined > (b, _) <- undefined > (c, _) <- undefined > undefined > > main = undefined > }}} > > It only happens with at least 3 of these pattern matches. New description: I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2). The compilation runs smoothly, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with a stack overflow error. I tried to find a minimal example that causes this behavior: {{{#!hs #!/usr/bin/env stack -- stack --resolver nightly-2017-08-25 script {-# LANGUAGE ApplicativeDo #-} x = do (a, _) <- undefined (b, _) <- undefined (c, _) <- undefined undefined main = undefined }}} It only happens with at least 3 of these pattern matches. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:06:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:06:47 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.5fce9de73d824b6746a20db7e132fe16@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: datacon-tags 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: => datacon-tags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:06:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:06:56 -0000 Subject: [GHC] #8317: Optimize tagToEnum# at Core level In-Reply-To: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> References: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> Message-ID: <063.08b8a028aa07fd3dae62dce25a1f8e9a@haskell.org> #8317: Optimize tagToEnum# at Core level -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 8326 | Blocking: Related Tickets: #6135 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => datacon-tags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:07:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:07:02 -0000 Subject: [GHC] #13182: Rethinking dataToTag# In-Reply-To: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> References: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> Message-ID: <060.72468f17d36139a7dee8f34e1ea32373@haskell.org> #13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: datacon-tags 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: => datacon-tags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:07:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:07:24 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.850a35a602544347906073f66fba5e55@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags 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: => datacon-tags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:10:09 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.2709f8efda4ed98e480829445b142ca1@haskell.org> #6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | primops/should_run/T6135 Blocked By: 8103, 8103 | Blocking: Related Tickets: #605 | Differential Rev(s): Wiki Page: PrimBool | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => datacon-tags Old description: > Right now the only way to compare two integers is with primops that > produce boxed bools: > > {{{ > <# :: Int# -> Int# -> Bool > ==# :: Int# -> Int# -> Bool > }}} > > To consume the resulting {{{Bool}}} we need a case-expression, which > introduces branches into the core IR and object code. Case expressions > are bad in the presence of heavy inlining because case-of-case performed > by the GHC simplifier tends to duplicate code (like in DPH and Repa > programs). Mis-predicted branches are bad in object code because they > stall the pipeline. > > Consider the following expression: > {{{ > case x <# 0# || x >=# aWidth > || y <# 0# || y >=# aHeight of > True -> ... > False -> ... > }}} > > This is very common in array programming. Ideally, it should turn into > some straight-line code to compute the flag, and then a single branch > instruction once we've worked out what alternative to take. However, as > the only way to consume the {{{Bool}}}s produced by the comparisons is to > introduce more case expressions, we end up with *four* cases in the core > IR. > > What I want is this: > {{{ > data Bool# > (.<#) :: Int# -> Int# -> Bool# > (.==#) :: Int# -> Int# -> Bool# > (.||#) :: Bool# -> Bool# -> Bool# > > case x .<# 0# .||# x .>=# aWidth > .||# y .<# 0# .||# y .>=# aHeight of > True# -> ... > False# -> ... > }}} > > Bool# is the type of one bit integers. I can compute with them > algebraically and be sure that I'll get at most one branch instruction in > the resulting object code. New description: Right now the only way to compare two integers is with primops that produce boxed bools: {{{#!hs <# :: Int# -> Int# -> Bool ==# :: Int# -> Int# -> Bool }}} To consume the resulting {{{Bool}}} we need a case-expression, which introduces branches into the core IR and object code. Case expressions are bad in the presence of heavy inlining because case-of-case performed by the GHC simplifier tends to duplicate code (like in DPH and Repa programs). Mis-predicted branches are bad in object code because they stall the pipeline. Consider the following expression: {{{#!hs case x <# 0# || x >=# aWidth || y <# 0# || y >=# aHeight of True -> ... False -> ... }}} This is very common in array programming. Ideally, it should turn into some straight-line code to compute the flag, and then a single branch instruction once we've worked out what alternative to take. However, as the only way to consume the {{{Bool}}}s produced by the comparisons is to introduce more case expressions, we end up with *four* cases in the core IR. What I want is this: {{{#!hs data Bool# (.<#) :: Int# -> Int# -> Bool# (.==#) :: Int# -> Int# -> Bool# (.||#) :: Bool# -> Bool# -> Bool# case x .<# 0# .||# x .>=# aWidth .||# y .<# 0# .||# y .>=# aHeight of True# -> ... False# -> ... }}} Bool# is the type of one bit integers. I can compute with them algebraically and be sure that I'll get at most one branch instruction in the resulting object code. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:25:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:25:45 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.b7071559702bf67908653029ec14339c@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Then I know what's going on, the `FreeConsole()` call that was there in the `cwrapper.c` before that broke under Windows 10 recently was detaching the caller from the console. I suspect now that this was done to now have the caller still handle signals. The issue was by putting it in `cwrapper` it broke in cases where the caller should handle it. such as when GHC calls GCC. So the call should actually be in `ghci.c` not in `cwrapper.c`, since here we *do* have an interactive session. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:25:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:25:51 -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.743923088a65a0a4a9270ba80a177898@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > Are you saying that it should be made False? Ah... no, for functions `int_cxt` is true if it is applied. Perhaps for join-points `preInlineUnconditionally` should never be True if `in_lam` is true. That validates what we are trying here. > But there is an exception to that: Inside a recursive join point we do set occ_in_lam. Yes: `occ_in_lam` is true for a join point precisely when that join point is the exit of a recursive loop! That's just what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 16:29:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 16:29:21 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.d6ea97c1f16d0e82938d5f6dfe786d49@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think your summary of the workarounds is right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 17:40:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 17:40:45 -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.b59c3667686d357ff484c7c7223bd90f@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): Thanks for the guidance, that nailed it: * The code `isJoinId bndr, isOneOcc (idOccInfo bndr), occ_in_lam (idOccInfo bndr)` reliably detects an exit join point now, it seems. (I guess this deserves its own function `isExitJoinPoint`) * When I create the join point, I add the correct `OccInfo`, so that this is there even before OccurAnal runs the next time. * In `simplLetUnfolding`, when I detect an exit join point, I do not creating an unfolding. This prevents unfolding in `completeCall` and `postInlineUnconditionally`. * In `preInlineUnconditionally` I check for exit join points explicityly. Maybe it would be cleaner to leave the unfolding alone and simply check for `isExitJoinPoint` in all three places… but no, the simplifier seems to throw away the `idOccInfo`. So better stick to not creating an unfolding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:01:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:01:18 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.f87284f54b5304b34a37bb323da25fb7@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"248ad30385acc0f81f1959b6345a7388be76dc85/ghc" 248ad30/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="248ad30385acc0f81f1959b6345a7388be76dc85" testsuite: Add test for #14128 Reviewers: austin, goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #14128 Differential Revision: https://phabricator.haskell.org/D3890 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:01:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:01:18 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.a8f1c482cad2c114ff907d9ba09b85e9@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"5266ab9059dffa741b172636f50f1fbfd491dbb4/ghc" 5266ab90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5266ab9059dffa741b172636f50f1fbfd491dbb4" Remove dll-split. This patch removes dll-split from the code base, the reason is dll-split no longer makes any sense. It was designed to split a dll in two, but we now already have many more symbols than would fit inside two dlls. So we need a third one. This means there's no point in having to maintain this list as it'll never work anyway and the solution isn't scalable. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3882 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:01:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:01:18 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.ac64b8825a8c299507e3693ae05b1620@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"db3a8e168ad81f54ec58eebc4c75a0eaad889daf/ghc" db3a8e16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db3a8e168ad81f54ec58eebc4c75a0eaad889daf" desugar: Ensure that a module's dep_orphs doesn't contain itself Consider that we have two modules, A and B, both with hs-boot files, * A.hs contains a SOURCE import of B * B.hs-boot contains a SOURCE import of A * A.hs-boot declares an orphan instance * A.hs defines the orphan instance In this case, B's dep_orphs will contain A due to its SOURCE import of A. Consequently, A will contain itself in its imp_orphs due to its import of B. This fact would end up being recorded in A's interface file. This would then break the invariant asserted by calculateAvails that a module does not itself in its dep_orphs. This was the cause of #14128. The solution is to remove self-references from imp_orphs when constructing dep_orphs; we already did a similar thing for dep_mods. I believe we should do the same for dep_finsts, although I'm treating this as a separate bug. Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3892 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:01:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:01:18 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.7beb8e5a50168a053c303dc43f132b38@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"895a7650a038131f3043f882c558c627abe9a61e/ghc" 895a7650/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="895a7650a038131f3043f882c558c627abe9a61e" Refactor type family instance abstract syntax declarations This implements @simonpj's suggested refactoring of the abstract syntax for type/data family instances (from https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines the previously separate `TyFamEqn` and `DataFamInstDecl` types into a single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed to before, where all of the implicit binders were embedded inside of `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them. Aside from some changes in parser test output, there is no change in behavior. Requires a Haddock submodule commit from my fork (at https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84 64b740c26255fd) Test Plan: ./validate Reviewers: simonpj, austin, goldfire, bgamari, alanz Reviewed By: bgamari Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj GHC Trac Issues: #14131 Differential Revision: https://phabricator.haskell.org/D3881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:06:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:06:06 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.d3f28fba6158ff048e19b95384cb9145@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: RyanGlScott => (none) * status: patch => new Comment: I believe more work is needed to fix the actual bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:11:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:11:34 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.3bdeb63b3e71c6c58c3469f2eb60cb52@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Phyx, can we consider this to be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:15:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:15:31 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.2253a2833890fc8f20a37861de86984a@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott Comment: Replying to [comment:18 bgamari]: > I believe more work is needed to fix the actual bug here. Indeed there is. I'll work on polishing up Phab:D3872 and fixing this ticket for good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:28:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:28:38 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.89885465cb5d7311a8dae330886f1204@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3897 Comment: So this is problematic: `lockPackageDb` first tries to open (and then exclusively lock) the lockfile as read-only to account for the possibility that we are opening a global package database for which we only have read access. However, NFS does not allow this as mentioned above. I believe Phab:D3897 is one possible fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:29:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:29:01 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.cdd0e1a9050b90fd72a8164d28f62477@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2592 => Phab:D2592 Phab:D3883 Phab:D3882 Comment: @bgamari, not yet. I would like Phab:D3883 to be merged first. I'll then open tickets for the rest of the work. I have more build and ghc changes locally I need to split and make patches for but wanted to do it piece wise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 18:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 18:32:38 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.cf447781257684bfafe7755155e66790@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: merge Priority: low | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Out of curiosity, what are you using the output of this command for, h4ck3rm1k3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 19:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 19:03:35 -0000 Subject: [GHC] #14154: Some cocktail of features causes GHC panic In-Reply-To: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> References: <051.eb1c6dc84859f8d5e3d56f701b3b1b3c@haskell.org> Message-ID: <066.2c7f7891f1eb4b5b12232d322f2a9795@haskell.org> #14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14154 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed, merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 19:06:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 19:06:24 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.7b423d114433623c596bfc683c8df0c4@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've also cherry-picked this to `ghc-8.2`. Of course, it would be great to have a better understanding of why this fixes the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 20:02:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 20:02:24 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.3b9539ee055c47fcc4bc639ebc6d8104@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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:D3872 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3872 Comment: ...and now Phab:D3872 is back! Re-setting the Differential revision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 20:03:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 20:03:04 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.b88a94d90d037b7dd7744dc6d7642b22@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch Comment: Phab:D3872 is ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 21:37:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 21:37:27 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.64369bbda57ac2ce041c48165843930f@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I have a pretty decent guess about the problem. We have {{{#!hs mkStmtTreeHeuristic :: [(ExprLStmt GhcRn, FreeVars)] -> ExprStmtTree mkStmtTreeHeuristic [one] = StmtTreeOne one mkStmtTreeHeuristic stmts = case segments stmts of [one] -> split one segs -> StmtTreeApplicative (map split segs) where split [one] = StmtTreeOne one split stmts = StmtTreeBind (mkStmtTreeHeuristic before) (mkStmtTreeHeuristic after) where (before, after) = splitSegment stmts }}} The `do` block in question can't actually be split at all (all the pattern matches are strict). So I ''think'' the trick is probably to make sure `before` is non-empty before producing `StmtTreeBind`. I'll give this a whirl. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 21:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 21:38:29 -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.169982166f978b73ca8e1cdcd37b2468@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): > the simplifier seems to throw away the idOccInfo. That's by design. The occ-info after simplification isn't necessarily valid. E.g. {{{ x = e f = \y. ...x... y = ...(f 1)...(f 2)... }}} Currently x occurs once, but after inlining `f` twice, `x` occurs twice. So the simplifier carefullly deletes it. (Except for robust info like "this lambda binder is dead".) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 21:56:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 21:56:38 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.281611f5d18397aa30190ca6ef5ffa1c@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 21:59:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 21:59:58 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails In-Reply-To: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> References: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> Message-ID: <059.d33c938817e97bcf7a40875a36f286cd@haskell.org> #14159: Decomposition of path sometimes fails ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3891 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"3c6b2fc3b5ca11a5410405664e4640767ef941dd/ghc" 3c6b2fc3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c6b2fc3b5ca11a5410405664e4640767ef941dd" Fix decomposition error on Windows Summary: Fix the path decomposition error that occurs when the Symlink resolver fails. `Win32.try` throws an exception, so catch it and assume the path isn't a symlink to use the old behavior. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14159 Differential Revision: https://phabricator.haskell.org/D3891 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 22:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 22:01:17 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails In-Reply-To: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> References: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> Message-ID: <059.1a0e14ca5b2ad17ea2997a073e5dca36@haskell.org> #14159: Decomposition of path sometimes fails ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3891 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => merge Comment: Please merge this into 8.2.2, it makes us able to move the binaries more freely again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 22:09:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 22:09:28 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.40d77be84f3aa50763f3a02ed30fe0b7@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"5f6a82040694f7c8c2b394c1b418c0167b963e0b/ghc" 5f6a8204/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f6a82040694f7c8c2b394c1b418c0167b963e0b" Add gen-dll as replacement for dll-split Summary: This tool can be used to generate dll's for any list of object files given to it. It will then repartition them automatically to fit within a dll and generates as many dll's as needed to do this. Cyclic dependencies between these generated dlls are handle automatically so there is no need to tell it how to partition. It is also a lot more general than `dll-split` as it is able to split any package not just `libGHC`. It also uses a trick using GNU style import libraries to hide the splitting from the rest of the pipeline. Which means come linking time you don't need to know which dll contains what symbol or how many split dlls were created. The import libraries are by default created with libtool. However since libtool is BFD based it is very slow. So if present and detected by configure the `genlib` tool from the msys2 project is used. This makes a difference of about ~45 minutes when compiling. To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`. More detailed explaination of the process can be found here https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 22:28:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 22:28:08 -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.d65ca969a2d8964be491bf2579c66d8e@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): Ok, so `wip/T14152` has an implementation that works (judging from looking at the Core output). It’s not polished, but good enough to play around to see what happens. It’s also inefficient (it should probably work on an fv- annotated syntax tree instead of recomputing the free variables repeatedly. But it still applies “exitification” only together with “loopification”. This makes it hard to evaluate the merits of this ticket independently of loopification. Also, if we want “exitification”, then we want it for all joinrecs. Is there a better place to do it? Should it simply be a pass on its own that we run maybe after the first simplifier (which introduces most joinrecs?)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 22:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 22:29:44 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.0ff007754027b136d8ec75a828115d21@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * blockedby: 10352 => Comment: I will open tickets for the rest of the patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 22:59:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 22:59:50 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.c0df979feb2b128e6b8f697a1b492a13@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed -------------------------------------+------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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 bgamari): * status: new => infoneeded * cc: Phyx- (added) Comment: Thanks for your report! Could you provide the output of `stack install --ghc-options=-v3 math- functions`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:05:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:05:27 -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.a9b8c9b9edada3dfa769b798ae83a98f@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): You could make two separate passes. Or one that (controlled by a flag) does either or both of loopification and exitification. Of course if it does both, it'd better do exitification to prior joinrecs and to the ones introduced by loopification My guess is that we'll want to do both at once, and do so once or at most twice in the pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:10:43 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.1b57ce1cd19d4855857f79dcf04a5fcc@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"f86de44dac0a6ca40c5fcd65f3a1944c45fa6011/ghc" f86de44/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f86de44dac0a6ca40c5fcd65f3a1944c45fa6011" ghc-pkg: Try opening lockfiles in read-write mode first As pointed out in #13945, some filesystems only allow allow exclusive locks if the fd being locked was opened for write access. This causes ghc-pkg to fail as it first attempts to open and exclusively lock its lockfile in read-only mode to accomodate package databases for which we lack write permissions (e.g. global package databases). Instead, we now try read-write mode first, falling back to read-only mode if this fails. Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13945 Differential Revision: https://phabricator.haskell.org/D3897 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:10:44 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.4e478c164cafac8635ac42f7185242c8@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"779b9e6965416ee08af6eb15354cf09e9f40e0d9/ghc" 779b9e6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="779b9e6965416ee08af6eb15354cf09e9f40e0d9" PackageDb: Explicitly unlock package database before closing Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13945 Differential Revision: https://phabricator.haskell.org/D3874 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:10:44 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.3852f6b6f173059dd84c19e62862f034@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.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:D3889 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a36b34c4821653e3db3ff24b903265a7750a3397/ghc" a36b34c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a36b34c4821653e3db3ff24b903265a7750a3397" StgLint: Enforce MultiValAlt liveness invariant only after unariser The unariser ensures that we never use case binders that are void, unboxed sums, or unboxed tuples. However, previously StgLint was enforcing this invariant even before the unariser was running, giving rise to spurious lint failures. Fix this. Following CoreLint, we introduce a LintFlags environment to the linter monad, allowing for additional flags to be easily accomodated in the future. See #14118. Test Plan: Build GHC with -dstg-lint Reviewers: simonpj, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14118 Differential Revision: https://phabricator.haskell.org/D3889 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:10:44 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.4492f4f64c55691ed87bd29ccdfcff23@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 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:D3879 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f17f1063a29452843195c59e6cca2191b9d46c7f/ghc" f17f106/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f17f1063a29452843195c59e6cca2191b9d46c7f" StgLint: Give up on trying to compare types We used to try a crude comparison of the type themselves, but this is essentially impossible in STG as we have discarded. both casts and type applications, so types might look different but be the same. Now we simply compare their runtime representations. See #14120. Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14120 Differential Revision: https://phabricator.haskell.org/D3879 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:12:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:12:23 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.efd04f409233a7078b04032341ddbde5@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => infoneeded Comment: My testing suggests that comment:14 should be sufficient to fix this. It would be great if someone could confirm this. Note that in my experience it is the boot compiler's `ghc-pkg` that fails, so you will need to build a new compiler with this patch and use it to bootstrap another tree to test this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:13:25 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.29972f15f0a6235c1499e8931d151604@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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:D3879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:13:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:13:36 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.74f1d6183d1fad96889400656b7aee6a@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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:D3889 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:16:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:16:31 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.c8017c3ff404b2fa34af2fe330dd9710@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * os: Unknown/Multiple => Windows * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Hmmm the output is quite suspicious. Both `expm1` and `GHC.Float` from the GHC build output show some character corruption. `mbstowcs` which `mkPath` uses fails when it encounters an invalid multibyte character. The source doesn't seem to contain this so I wonder where the corruption happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:19:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:19:15 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.d7c03340864e2cd35831bdbf7fd75964@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 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: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6f1ccaa50f905bdc586a7a92ab7e38e30c1e7ff5/ghc" 6f1ccaa5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f1ccaa50f905bdc586a7a92ab7e38e30c1e7ff5" Add a Note describing #14128 I prematurely committed the D3892 before adding a Note. Fix this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:20:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:20:19 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.817beeee413be3076b1b8af3af7620a3@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: => Phab:D3900 Comment: I have a workaround: if the splitter doesn't actually split, just pull off the first statement and the rest and form a `StmtTreeBind`. But I don't yet understand enough to see why we have this problem with strict patterns and not with other dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:25:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:25:47 -0000 Subject: [GHC] #14166: Typo Fix `necssary` In-Reply-To: <049.5d630cac9b72315235a0b59455deec53@haskell.org> References: <049.5d630cac9b72315235a0b59455deec53@haskell.org> Message-ID: <064.720c4367e547d45b180bb0f5ca399ba6@haskell.org> #14166: Typo Fix `necssary` -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 29 23:33:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Aug 2017 23:33:38 -0000 Subject: [GHC] #14169: ghci panics when using type applications on variables that aren't in scope Message-ID: <048.5351e59bb9113043a18e362d2f31519f@haskell.org> #14169: ghci panics when using type applications on variables that aren't in scope -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Minimal example: {{{#!hs ghci> foo @Int ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] foo_a7EJ :: t_a7EI[tau:1] (CHoleCan: foo) [W] foo_a7F7 :: t_a7F6[tau:1] (CHoleCan: foo)} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 00:01:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 00:01:51 -0000 Subject: [GHC] #14169: ghci panics when using type applications on variables that aren't in scope In-Reply-To: <048.5351e59bb9113043a18e362d2f31519f@haskell.org> References: <048.5351e59bb9113043a18e362d2f31519f@haskell.org> Message-ID: <063.28d10268dc31077e90e830454ac5401e@haskell.org> #14169: ghci panics when using type applications on variables that aren't in scope -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: #13466 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13466 Comment: Thanks for the bug report. This is a duplicate of #13466, which has been fixed in GHC 8.2.1: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications λ> foo @Int :2:1: error: Variable not in scope: foo :2:1: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: foo @Int In an equation for ‘it’: it = foo @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 00:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 00:30:43 -0000 Subject: [GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't In-Reply-To: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> References: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> Message-ID: <065.9b2c4cf6b0d63ad9d7771da4d735967f@haskell.org> #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GADTs, | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3901 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3901 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 03:19:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 03:19:45 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.7ae1a0b77dad3bd1804072949f767b1a@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Qinka): (More informations) The output for `stack install --ghc-options=-v3 math-functions` {{{ λ stack install --ghc-options=-v3 math-functions math-functions-0.2.1.0: configure math-functions-0.2.1.0: build -- While building package math-functions-0.2.1.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 255 Logs have been written to: A:\Glob\.stack-work\logs\math- functions-0.2.1.0.log Configuring math-functions-0.2.1.0... Preprocessing library for math-functions-0.2.1.0.. Building library for math-functions-0.2.1.0.. [ 1 of 10] Compiling Numeric.MathFunctions.Comparison ( Numeric\MathFunctions\Comparison.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Comparison.o ) [ 2 of 10] Compiling Numeric.MathFunctions.Constants ( Numeric\MathFunctions\Constants.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Constants.o ) [ 3 of 10] Compiling Numeric.Polynomial ( Numeric\Polynomial.hs, .stack-work\dist\e53504d9\build\Numeric\Polynomial.o ) [ 4 of 10] Compiling Numeric.Polynomial.Chebyshev ( Numeric\Polynomial\Chebyshev.hs, .stack- work\dist\e53504d9\build\Numeric\Polynomial\Chebyshev.o ) [ 5 of 10] Compiling Numeric.RootFinding ( Numeric\RootFinding.hs, .stack-work\dist\e53504d9\build\Numeric\RootFinding.o ) [ 6 of 10] Compiling Numeric.Series ( Numeric\Series.hs, .stack- work\dist\e53504d9\build\Numeric\Series.o ) [ 7 of 10] Compiling Numeric.SpecFunctions.Internal ( Numeric\SpecFunctions\Internal.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Internal.o ) C:\Users\qinka\AppData\Local\Temp\stack15552\math- functions-0.2.1.0\Numeric\SpecFunctions\Internal.hs:24:1: warning: [-Wunused-imports] The import of 鈥榚xpm1鈥?from module 鈥楪HC.Float鈥?is redundant | 24 | import GHC.Float (log1p,expm1) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 8 of 10] Compiling Numeric.SpecFunctions.Extra ( Numeric\SpecFunctions\Extra.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Extra.o ) [ 9 of 10] Compiling Numeric.SpecFunctions ( Numeric\SpecFunctions.hs, .stack-work\dist\e53504d9\build\Numeric\SpecFunctions.o ) [10 of 10] Compiling Numeric.Sum ( Numeric\Sum.hs, .stack- work\dist\e53504d9\build\Numeric\Sum.o ) ghc.EXE: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} The output for `stack install --verbose math-functions` {{{ λ stack install --verbose math-functions Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd x86_64 hpack-0.17.0 2017-08-30 11:16:38.241189: [debug] Checking for project config at: A:\Glob\stack.yaml @(Stack\Config.hs:935:9) 2017-08-30 11:16:38.242667: [debug] Loading project config file stack.yaml @(Stack\Config.hs:960:13) 2017-08-30 11:16:38.251672: [debug] Trying to decode C:\sr\build-plan- cache\x86_64-windows\nightly-2017-08-29.cache @(Data\Store\VersionTagged.hs:68:5) 2017-08-30 11:16:38.272167: [debug] Success decoding C:\sr\build-plan- cache\x86_64-windows\nightly-2017-08-29.cache @(Data\Store\VersionTagged.hs:72:13) 2017-08-30 11:16:38.281672: [debug] Using standard GHC build @(Stack\Setup.hs:600:9) 2017-08-30 11:16:38.285672: [debug] Getting Cabal package version @(Stack\GhcPkg.hs:189:5) 2017-08-30 11:16:38.288172: [debug] Getting global package database location @(Stack\GhcPkg.hs:55:5) 2017-08-30 11:16:38.288670: [debug] Asking GHC for its version @(Stack\Setup\Installed.hs:103:13) 2017-08-30 11:16:38.290170: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db field --simple-output Cabal version @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.290674: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db list --global @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.296670: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.EXE --numeric-version @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.364167: [debug] Process finished in 61ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.EXE --numeric-version @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.384387: [debug] Process finished in 91ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db list --global @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.384888: [debug] Process finished in 92ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db field --simple-output Cabal version @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.385889: [debug] Resolving package entries @(Stack\Setup.hs:254:5) 2017-08-30 11:16:38.387888: [debug] Starting to execute command inside EnvConfig @(Stack\Runners.hs:166:18) 2017-08-30 11:16:38.388386: [debug] Parsing the cabal files of the local packages @(Stack\Build\Source.hs:310:5) 2017-08-30 11:16:38.399389: [debug] Parsing the targets @(Stack\Build\Source.hs:247:5) 2017-08-30 11:16:38.400391: [debug] Exception ignored when attempting to load A:\Glob\glob-auth\.stack-work\dist\e53504d9\stack-build-cache: A:\Glob\glob-auth\.stack-work\dist\e53504d9\stack-build-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:38.401389: [debug] Start: getPackageFiles A:\Glob\glob- auth\glob-auth.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.415390: [debug] Finished in 13ms: getPackageFiles A:\Glob\glob-auth\glob-auth.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.419889: [debug] Exception ignored when attempting to load A:\Glob\glob-core\.stack-work\dist\e53504d9\stack-build-cache: A:\Glob\glob-core\.stack-work\dist\e53504d9\stack-build-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:38.420890: [debug] Start: getPackageFiles A:\Glob\glob- core\glob-core.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.443886: [debug] Finished in 22ms: getPackageFiles A:\Glob\glob-core\glob-core.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.446886: [debug] Exception ignored when attempting to load A:\Glob\glob-launch\.stack-work\dist\e53504d9\stack-build-cache: A:\Glob\glob-launch\.stack-work\dist\e53504d9\stack-build-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:38.447386: [debug] Start: getPackageFiles A:\Glob\glob- launch\glob-launch.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.455888: [debug] Finished in 8ms: getPackageFiles A:\Glob\glob-launch\glob-launch.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.458389: [debug] Exception ignored when attempting to load A:\Glob\glob-tool\.stack-work\dist\e53504d9\stack-build-cache: A:\Glob\glob-tool\.stack-work\dist\e53504d9\stack-build-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:38.459393: [debug] Start: getPackageFiles A:\Glob\glob- tool\glob-tool.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.479886: [debug] Finished in 19ms: getPackageFiles A:\Glob\glob-tool\glob-tool.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.483889: [debug] Exception ignored when attempting to load A:\Glob\glob-utils\.stack-work\dist\e53504d9\stack-build-cache: A:\Glob\glob-utils\.stack-work\dist\e53504d9\stack-build-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:38.484387: [debug] Start: getPackageFiles A:\Glob\glob- utils\glob-utils.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.499394: [debug] Finished in 14ms: getPackageFiles A:\Glob\glob-utils\glob-utils.cabal @(Stack\Package.hs:251:21) 2017-08-30 11:16:38.504387: [debug] Finding out which packages are already installed @(Stack\Build\Installed.hs:69:5) 2017-08-30 11:16:38.507888: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --global --no-user-package-db dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.585888: [debug] Process finished in 77ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --global --no-user-package-db dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.613903: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapshots\4c52f22a\pkgdb dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.764389: [debug] Process finished in 148ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapshots\4c52f22a\pkgdb dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.769388: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --no-user-package-db --package-db A:\Glob\.stack- work\install\068939cd\pkgdb dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.814388: [debug] Process finished in 43ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --no-user-package-db --package-db A:\Glob\.stack- work\install\068939cd\pkgdb dump --expand-pkgroot @(System\Process\Read.hs:306:3) 2017-08-30 11:16:38.816887: [debug] Constructing the build plan @(Stack\Build\ConstructPlan.hs:158:5) 2017-08-30 11:16:38.819887: [debug] Trying to decode C:\sr\indices\Tsinghua\01-index.cache @(Data\Store\VersionTagged.hs:68:5) 2017-08-30 11:16:38.937963: [debug] Success decoding C:\sr\indices\Tsinghua\01-index.cache @(Data\Store\VersionTagged.hs:72:13) 2017-08-30 11:16:39.140290: [debug] Checking if we are going to build multiple executables with the same name @(Stack\Build.hs:210:5) 2017-08-30 11:16:39.141290: [debug] Executing the build plan @(Stack\Build\Execute.hs:458:5) 2017-08-30 11:16:39.142789: [debug] Getting global package database location @(Stack\GhcPkg.hs:55:5) 2017-08-30 11:16:39.143288: [debug] Run process: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db list --global @(System\Process\Read.hs:306:3) 2017-08-30 11:16:39.196673: [debug] Process finished in 52ms: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --no-user-package-db list --global @(System\Process\Read.hs:306:3) 2017-08-30 11:16:39.198175: [debug] Precompiled cache input = (["-- dependency=base=base-4.10.0.0","--dependency=deepseq=deepseq-1.4.3.0","-- dependency=primitive=primitive-0.6.2.0-V0ibjLQDdN6fcQS5bjLVg","-- dependency=vector=vector-0.12.0.1-CnPH69pDwM4A5esizlXfXi","--dependency =vector-th-unbox=vector-th-unbox-0.2.1.6-JdDbsOZxikU7Wr8hmBip1S","--extra- include- dirs=C:\\Users\\qinka\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20161025\\mingw64\\include ","--extra-lib- dirs=C:\\Users\\qinka\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20161025\\mingw64\\lib"],fromList ["base-4.10.0.0","deepseq-1.4.3.0","primitive-0.6.2.0-V0ibjLQDdN6fcQS5bjLVg","vector-0.12.0.1-CnPH69pDwM4A5esizlXfXi ","vector-th-unbox-0.2.1.6-JdDbsOZxikU7Wr8hmBip1S"]) @(Stack\Build\Cache.hs:283:5) 2017-08-30 11:16:39.200677: [debug] Exception ignored when attempting to load C:\sr\precompiled\x86_64-windows\ghc-8.2.1\2.0.0.2\math- functions-0.2.1.0\noe5BbegP8iihQXKEZ82ZfRDWhSyn6fbIWQ1qhDvkAE=: C:\sr\precompiled\x86_64-windows\ghc-8.2.1\2.0.0.2\math- functions-0.2.1.0\noe5BbegP8iihQXKEZ82ZfRDWhSyn6fbIWQ1qhDvkAE=: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:39.352671: [debug] Exception ignored when attempting to load C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-config-cache: C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-config-cache: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:39.354171: [debug] Exception ignored when attempting to load C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-cabal-mod: C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-cabal-mod: openBinaryFile: does not exist (No such file or directory) @(Data\Store\VersionTagged.hs:86:9) 2017-08-30 11:16:39.355171: [info] math-functions-0.2.1.0: configure @(Stack\Build\Execute.hs:830:23) 2017-08-30 11:16:39.428672: [debug] Run process: C:\sr\setup-exe- cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 configure --with- ghc=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.EXE --with-ghc- pkg=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --package-db=clear --package-db=global --package- db=C:\sr\snapshots\4c52f22a\pkgdb --libdir=C:\sr\snapshots\4c52f22a\lib --bindir=C:\sr\snapshots\4c52f22a\bin --datadir=C:\sr\snapshots\4c52f22a\share --libexecdir=C:\sr\snapshots\4c52f22a\libexec --sysconfdir=C:\sr\snapshots\4c52f22a\etc --docdir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --htmldir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --haddockdir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --dependency=base=base-4.10.0.0 --dependency=deepseq=deepseq-1.4.3.0 --dependency=primitive=primitive-0.6.2.0-V0ibjLQDdN6fcQS5bjLVg --dependency=vector=vector-0.12.0.1-CnPH69pDwM4A5esizlXfXi --dependency =vector-th-unbox=vector-th-unbox-0.2.1.6-JdDbsOZxikU7Wr8hmBip1S --extra- include- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\include --extra-lib- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\lib @(System\Process\Read.hs:340:3) 2017-08-30 11:16:41.061549: [debug] Process finished in 1630ms: C:\sr \setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 configure --with- ghc=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.EXE --with-ghc- pkg=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --package-db=clear --package-db=global --package- db=C:\sr\snapshots\4c52f22a\pkgdb --libdir=C:\sr\snapshots\4c52f22a\lib --bindir=C:\sr\snapshots\4c52f22a\bin --datadir=C:\sr\snapshots\4c52f22a\share --libexecdir=C:\sr\snapshots\4c52f22a\libexec --sysconfdir=C:\sr\snapshots\4c52f22a\etc --docdir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --htmldir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --haddockdir=C:\sr\snapshots\4c52f22a\doc\math-functions-0.2.1.0 --dependency=base=base-4.10.0.0 --dependency=deepseq=deepseq-1.4.3.0 --dependency=primitive=primitive-0.6.2.0-V0ibjLQDdN6fcQS5bjLVg --dependency=vector=vector-0.12.0.1-CnPH69pDwM4A5esizlXfXi --dependency =vector-th-unbox=vector-th-unbox-0.2.1.6-JdDbsOZxikU7Wr8hmBip1S --extra- include- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\include --extra-lib- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\lib @(System\Process\Read.hs:340:3) 2017-08-30 11:16:41.063547: [debug] Encoding C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-config-cache @(Data\Store\VersionTagged.hs:51:5) 2017-08-30 11:16:41.066049: [debug] Finished writing C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-config-cache @(Data\Store\VersionTagged.hs:55:5) 2017-08-30 11:16:41.066551: [debug] Encoding C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-cabal-mod @(Data\Store\VersionTagged.hs:51:5) 2017-08-30 11:16:41.072547: [debug] Finished writing C:\Users\qinka\AppData\Local\Temp\stack13180\math-functions-0.2.1.0 \.stack-work\dist\e53504d9\stack-cabal-mod @(Data\Store\VersionTagged.hs:55:5) 2017-08-30 11:16:41.073556: [info] math-functions-0.2.1.0: build @(Stack\Build\Execute.hs:830:23) 2017-08-30 11:16:41.074560: [debug] Run process: C:\sr\setup-exe- cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" @(System\Process\Read.hs:340:3) -- While building package math-functions-0.2.1.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 255 Logs have been written to: A:\Glob\.stack-work\logs\math- functions-0.2.1.0.log Configuring math-functions-0.2.1.0... Preprocessing library for math-functions-0.2.1.0.. Building library for math-functions-0.2.1.0.. [ 1 of 10] Compiling Numeric.MathFunctions.Comparison ( Numeric\MathFunctions\Comparison.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Comparison.o ) [ 2 of 10] Compiling Numeric.MathFunctions.Constants ( Numeric\MathFunctions\Constants.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Constants.o ) [ 3 of 10] Compiling Numeric.Polynomial ( Numeric\Polynomial.hs, .stack-work\dist\e53504d9\build\Numeric\Polynomial.o ) [ 4 of 10] Compiling Numeric.Polynomial.Chebyshev ( Numeric\Polynomial\Chebyshev.hs, .stack- work\dist\e53504d9\build\Numeric\Polynomial\Chebyshev.o ) [ 5 of 10] Compiling Numeric.RootFinding ( Numeric\RootFinding.hs, .stack-work\dist\e53504d9\build\Numeric\RootFinding.o ) [ 6 of 10] Compiling Numeric.Series ( Numeric\Series.hs, .stack- work\dist\e53504d9\build\Numeric\Series.o ) [ 7 of 10] Compiling Numeric.SpecFunctions.Internal ( Numeric\SpecFunctions\Internal.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Internal.o ) C:\Users\qinka\AppData\Local\Temp\stack13180\math- functions-0.2.1.0\Numeric\SpecFunctions\Internal.hs:24:1: warning: [-Wunused-imports] The import of 鈥榚xpm1鈥?from module 鈥楪HC.Float鈥?is redundant | 24 | import GHC.Float (log1p,expm1) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 8 of 10] Compiling Numeric.SpecFunctions.Extra ( Numeric\SpecFunctions\Extra.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Extra.o ) [ 9 of 10] Compiling Numeric.SpecFunctions ( Numeric\SpecFunctions.hs, .stack-work\dist\e53504d9\build\Numeric\SpecFunctions.o ) [10 of 10] Compiling Numeric.Sum ( Numeric\Sum.hs, .stack- work\dist\e53504d9\build\Numeric\Sum.o ) ghc.EXE: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 07:53:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 07:53:21 -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.55337882963a97a4ce24685f92fcf6ea@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new 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): Note that loopification is not really a pass: The information of whether we can do it falls out of the simplifier, and the change to the AST is a simple local change and O(1). I will turn exitification into a pass of its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 12:53:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 12:53:22 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` Message-ID: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When GHC 8.2.1 compiles this code with `-O`: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module NatVal where import Data.Proxy import GHC.TypeLits foo = natVal $ Proxy @0 }}} it produces the following Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} NatVal.foo1 :: Integer NatVal.foo1 = 0 -- RHS size: {terms: 41, types: 18, coercions: 0, joins: 0/0} foo :: Integer foo = case NatVal.foo1 of wild_a1iV { integer-gmp-1.0.1.0:GHC.Integer.Type.S# i#_a2ke -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# i#_a2ke 0#) of { False -> case GHC.Natural.underflowError of wild2_00 { }; True -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger (GHC.Prim.int2Word# i#_a2ke) }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# dt_a2km -> case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt_a2km) 3# of { __DEFAULT -> case GHC.Prim.sizeofByteArray# dt_a2km of { __DEFAULT -> wild_a1iV; 0# -> case GHC.Natural.underflowError of wild4_00 { } }; 1# -> case GHC.Prim.indexWordArray# dt_a2km 0# of wild2_a2kq { __DEFAULT -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger wild2_a2kq } }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# ipv_a2kt -> case GHC.Natural.underflowError of wild1_00 { } } }}} while GHC-8.0.1 does the right thing: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0} foo :: Integer foo = 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 14:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 14:59:01 -0000 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> References: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> Message-ID: <068.82096f0f4b51b56f524cbb1d53694638@haskell.org> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): From this thread, I just found out that `QSem` defined in base in deprecated. It would be nice if this were mentioned in the haddock for `QSem`: http://hackage.haskell.org/package/base-4.10.0.0/docs/Control- Concurrent-QSem.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 16:26:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 16:26:02 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.3f56a75433084d4c24268081d13da84d@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"567dca6ee1e32afdc5409e2e9d91d9e5c14a65c5/ghc" 567dca6e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="567dca6ee1e32afdc5409e2e9d91d9e5c14a65c5" Add some traceRn and (Outputable StmtTree) I added these when investigating Trac #14163, but they'll be useful anyway. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 19:34:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 19:34:22 -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.8cd03eedd7c35bce03de807d7b513b40@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I was able to track this down to commit 1fcede43d2b30f33b7505e25eb6b1f321be0407f (`Introduce GHC.TypeNats module, change KnownNat evidence to be Natural`), which hints at the problem. In that commit, we switched the internal representation of `Nat`s from `Integer`s to `Natural`s (from `Numeric.Natural`). For whatever reason, however, `Natural` values don't seem to simplify as well as `Integers`, as evidenced by this simpler program: {{{#!hs module Bug where import Numeric.Natural foo :: Natural foo = 0 }}} which also produces essentially identical core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Bug.foo1 :: Integer [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] Bug.foo1 = 0 -- RHS size: {terms: 39, types: 12, coercions: 0, joins: 0/0} foo :: Natural [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 126 60}] foo = case Bug.foo1 of { integer-gmp-1.0.1.0:GHC.Integer.Type.S# i#_a2bZ -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# i#_a2bZ 0#) of { False -> GHC.Natural.underflowError @ Natural; True -> GHC.Natural.NatS# (GHC.Prim.int2Word# i#_a2bZ) }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# dt_a2c9 -> case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt_a2c9) 3# of { __DEFAULT -> case GHC.Prim.sizeofByteArray# dt_a2c9 of { __DEFAULT -> GHC.Natural.NatJ# dt_a2c9; 0# -> GHC.Natural.underflowError @ Natural }; 1# -> case GHC.Prim.indexWordArray# dt_a2c9 0# of wild2_a2cd { __DEFAULT -> GHC.Natural.NatS# wild2_a2cd } }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# ipv_a2cg -> GHC.Natural.underflowError @ Natural } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 30 19:39:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Aug 2017 19:39:20 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.5c53a5f2f242b3a0adc8794ceab34ed6@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 14131 Related Tickets: | Differential Rev(s): Phab:D3902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D3872 => Phab:D3902 * blocking: => 14131 Comment: I decided to split this off into its own Diff, since it's a somewhat hefty patch by itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 02:13:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 02:13:53 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.ff4b39f300e6bf9c98e03bd7cf28d35f@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): HI, would it be possible for you to try this with just cabal-install? or a different version of the same package from stackage? from your first paste it seems that `-v3` wasn't actually passed to GHC. what shell are you running stack from? could you try just cmd? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 02:21:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 02:21:34 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.c83878664f55aa0f6b14b70703fc1351@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by patrickdoc): Do we want to include the Haddock and Cabal guides in distributions? As it stands right now, the distribution only has the zipped html of the Haddock guide. We could also provide full html (which would be browsable like the GHC guide) and/or a pdf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 02:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 02:29:09 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit Message-ID: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------------+---------------------------------- Reporter: MichaelBurge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/stm | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- Observed behavior: * The below program exits with return code 0 between the call to 'error "derp2"' and the call to 'error "derp"' * If the statement 'error "derp2"' is uncommented, the program will terminate with an exception. * The program only exits without output with -O. And in particular, with no-ignore-interface-pragmas. Expected behavior: * The program should terminate with an exception regardless of whether 'error "derp2"' is commented out or not. {{{#!hs module Main where import Control.Concurrent.STM import Control.Concurrent.STM.TVar data A = A String deriving (Eq, Show) data E = E { a :: TVar [Int], b :: TVar A, c :: TVar [Int] } consistency_1 :: E -> STM Bool consistency_1 = \e -> do _ <- readTVar $ c e return True installSanityChecks :: E -> IO () installSanityChecks e = do x e error "derp" x e = do atomically $ mapM_ installCheck [ consistency_1 ] -- error "derp2" where installCheck check = always $ check e main :: IO () main = do state <- initialize installSanityChecks state initialize :: IO E initialize = E <$> newTVarIO [] <*> newTVarIO (A "USD") <*> newTVarIO [] }}} Build options: (Remove -O and it will show the error) {{{ /home/mburge/tmp/ghc/ghc-8.2.1/build/bin/ghc \ -O \ -package-id base-4.10.0.0 \ -package-id stm-2.4.4.1-2iQ3ZIiQ6vc4AnCVcs8oMd \ app/Main.hs \ -package-db /home/mburge/.stack/snapshots/x86_64-linux/nightly-2017-08-24/8.2.1/pkgdb }}} I used a fresh copy of GHC installed from here: https://www.haskell.org/ghc/download.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 04:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 04:46:52 -0000 Subject: [GHC] #14172: GHC hangs during type-checking Message-ID: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.2 doesn't terminate when type checking this file: {{{#!hs import Control.Lens import Data.Functor.Compose traverseCompose :: (a -> f b) -> g a -> f (h _) traverseCompose = _Wrapping Compose . traverse }}} This is the smallest type signature I could find that still causes the problem. GHCi infers the type without issue, and when I annotate it with the correct type signature, the file is successfully compiled. Using base-4.9.1.0, lens-4.14.1, and transformers-0.5.2.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 04:48:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 04:48:56 -0000 Subject: [GHC] #14173: GHC hangs during type-checking Message-ID: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> #14173: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.2 doesn't terminate when type checking this file: {{{#!hs import Control.Lens import Data.Functor.Compose traverseCompose :: (a -> f b) -> g a -> f (h _) traverseCompose = _Wrapping Compose . traverse }}} This is the smallest type signature I could find that still causes the problem. GHCi infers the type without issue, and when I annotate it with the correct type signature, the file is successfully compiled. Using base-4.9.1.0, lens-4.15.1, and transformers-0.5.2.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 04:51:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 04:51:02 -0000 Subject: [GHC] #14173: GHC hangs during type-checking In-Reply-To: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> References: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> Message-ID: <067.0102fe5c7b29be001d5b7fa7c9918e76@haskell.org> #14173: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lightandlight): * version: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 06:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 06:43:23 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.ebc74b84dffc14040f1dddac4f7c7bff@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) Comment: I'm still seeing this with a profiling ghc. The `ghc-stage2.prof` can't be read. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 07:17:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 07:17:15 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.33707b6a23e005c4a1cea49abc8c16b9@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2c133b67df374c73bc8069cefd7d57e1d2a14fc3/ghc" 2c133b67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c133b67df374c73bc8069cefd7d57e1d2a14fc3" Really fix Trac #14158 I dug more into how #14158 started working. I temporarily reverted the patch that "fixed" it, namely commit a6c448b403dbe8720178ca82100f34baedb1f47e Author: Simon Peyton Jones Date: Mon Aug 28 17:33:59 2017 +0100 Small refactor of getRuntimeRep Sure enough, there was a real bug, described in the new TcExpr Note [Visible type application zonk] In general, syntactic substituion should be kind-preserving! Maybe we should check that invariant... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 07:20:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 07:20:24 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.a0bb964d089fb7a63c936d9337b80085@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14158 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T14158 Comment: Now I think I've nailed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 07:36:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 07:36:45 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.850d64f6904d71943e20cdd47cfbaf14@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @lippling: there's one other workaround, which is to add a ~ to your patterns, like so: {{{ x = do ~(a, _) <- undefined ~(b, _) <- undefined ~(c, _) <- undefined undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 09:17:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 09:17:34 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.a873f621c07e56cb503a54f2cc45e525@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Seems to work OK with HEAD. What about with 8.2? With HEAD I get {{{ T14172.hs:7:19: error: • Occurs check: cannot construct the infinite type: a ~ g'1 a Expected type: (f'0 a -> f (f'0 b)) -> Compose f'0 g'1 a -> f (h a') Actual type: (Unwrapped (Compose f'0 g'1 a) -> f (Unwrapped (h a'))) -> Compose f'0 g'1 a -> f (h a') • In the first argument of ‘(.)’, namely ‘_Wrapping Compose’ In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse • Relevant bindings include traverseCompose :: (a -> f b) -> g a -> f (h a') (bound at T14172.hs:7:1) | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^ T14172.hs:7:19: error: • Couldn't match type ‘g’ with ‘Compose f'0 g'1’ ‘g’ is a rigid type variable bound by the inferred type of traverseCompose :: (a -> f b) -> g a -> f (h a') at T14172.hs:7:1-46 Expected type: (a -> f b) -> g a -> f (h a') Actual type: (a -> f b) -> Compose f'0 g'1 a -> f (h a') • In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse • Relevant bindings include traverseCompose :: (a -> f b) -> g a -> f (h a') (bound at T14172.hs:7:1) | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 09:24:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 09:24:30 -0000 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> References: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> Message-ID: <068.5c4a3fe44f0ed0553e45671d1a232fa6@haskell.org> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): QSem and QSemN aren't deprecated, they were subsequently rewritten (after this thread) to be exception-safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 09:53:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 09:53:47 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.f89533322aa493a363dedbf065d91f58@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): @simonmar: Thanks! Good to know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 10:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 10:03:29 -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.414a54b2039e88184924ec6c09bbfdd2@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK here's the deal. * In the olden days we represented in `Integer` literal, say 3, in Core by `S# 3#`; that is, we exposed its reprsentation. That made constant folding of `plusInteger 3 5` hard, becuase it meant inlining `plusInteger` which is remarkably big. Result: tons of useless clutter. * Nowadays an `Integer` literal, say 3, is represented in GHC by `Lit (LitInteger 3)`, and ''not'' by an application of the data constructor `S#`. This latter expansion is done right at the end, by `CorePrep`. * That makes constant-folding, like `3+4` rewriting to `7` much, much easier. * We refrain from inlining things like `plusInteger`, `negateInteger` etc until a later stage, and instead add constant-folding rwerite rules for each of these functions. By delaying inlining, the constant-folding rewrite rules (all in `compiler/prelude/PrelRules`) have a decent chance to fire first. * However, in introducing `Natural` we failed to do any of this. The code {{{ foo :: Natural foo = 0 }}} turns into `foo = naturalFromInteger (0::Integer)`, and `naturalFromInteger` has an INLINE pragma. The right thing is presumably to treat `Natural` just like we treat `Integer`: * Keep it as a `LitInteger`. Conveniently `LitInteger` already stores its type, so we can distinguish literal integers from naturals. * Expand the literal in `CorePrep`. * Delay the inlining of `Natural` operations. * Add constant-folding rewrite rules to `PrelRules` I suppose we could also consider making `exprIsConApp_maybe` on an `Integer` literal return `S# n` or whatnot; just possibly that'd be useful anyway, but only for funcions that lack a constant-fold rewrite rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 12:45:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 12:45:56 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.7c640ffbdc799fbffac653eb74115f6c@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Is this a duplicate of #14034 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 13:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 13:32:02 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.fb0699ddef1c1f3e5b0d2b69ede1ab3b@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So this is odd. I tried running the example file (after installing the `lens` package) on GHC 8.2.1, and while it didn't loop forever, it //did// stack overflow: {{{ $ /opt/ghc/8.2.1/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:7:19: error: • Reduction stack overflow; size = 201 When simplifying the following type: g ~ Compose f'0 g'0 Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Which certainly isn't good. I then tried to remove external dependencies: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Lens where import Data.Coerce import Data.Functor.Compose import Data.Functor.Identity class Profunctor p where dimap :: (a -> b) -> (c -> d) -> p b c -> p a d (#.) :: Coercible c b => (b -> c) -> p a b -> p a c instance Profunctor (->) where dimap ab cd bc = cd . bc . ab {-# INLINE dimap #-} (#.) _ = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b {-# INLINE (#.) #-} type Iso s t a b = forall p f. (Profunctor p, Functor f) => p a (f b) -> p s (f t) type Iso' s a = Iso s s a a iso :: (s -> a) -> (b -> t) -> Iso s t a b iso sa bt = dimap sa (fmap bt) {-# INLINE iso #-} type AnIso s t a b = Exchange a b a (Identity b) -> Exchange a b s (Identity t) data Exchange a b s t = Exchange (s -> a) (b -> t) instance Profunctor (Exchange a b) where dimap f g (Exchange sa bt) = Exchange (sa . f) (g . bt) {-# INLINE dimap #-} (#.) _ = coerce {-# INLINE ( #. ) #-} withIso :: AnIso s t a b -> ((s -> a) -> (b -> t) -> r) -> r withIso ai k = case ai (Exchange id Identity) of Exchange sa bt -> k sa (runIdentity #. bt) {-# INLINE withIso #-} class Wrapped s where type Unwrapped s :: * _Wrapped' :: Iso' s (Unwrapped s) class Wrapped s => Rewrapped (s :: *) (t :: *) class (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (t ~ Compose f' g' a') => Rewrapped (Compose f g a) t instance Wrapped (Compose f g a) where type Unwrapped (Compose f g a) = f (g a) _Wrapped' = iso getCompose Compose _Wrapping :: Rewrapping s t => (Unwrapped s -> s) -> Iso s t (Unwrapped s) (Unwrapped t) _Wrapping _ = _Wrapped {-# INLINE _Wrapping #-} _Wrapped :: Rewrapping s t => Iso s t (Unwrapped s) (Unwrapped t) _Wrapped = withIso _Wrapped' $ \ sa _ -> withIso _Wrapped' $ \ _ bt -> iso sa bt {-# INLINE _Wrapped #-} }}} {{{#!hs module Bug where import Data.Functor.Compose import Lens traverseCompose :: (a -> f b) -> g a -> f (h _) traverseCompose = _Wrapping Compose . traverse }}} However, once I do that, compiling with GHC 8.2.1 no longer stack overflows! {{{ $ /opt/ghc/8.2.1/bin/ghc -c -O Lens.hs $ /opt/ghc/8.2.1/bin/ghc -c -O Bug.hs Bug.hs:6:46: error: • Found type wildcard ‘_’ standing for ‘a'’ Where: ‘a'’ is a rigid type variable bound by the inferred type of traverseCompose :: (a -> f b) -> g a -> f (h a') at Bug.hs:7:1-46 To use the inferred type, enable PartialTypeSignatures • In the type signature: traverseCompose :: (a -> f b) -> g a -> f (h _) | 6 | traverseCompose :: (a -> f b) -> g a -> f (h _) | ^ Bug.hs:7:19: error: • Occurs check: cannot construct the infinite type: a ~ g'1 a Expected type: (f'0 a -> f (f'0 b)) -> Compose f'0 g'1 a -> f (h a') Actual type: (Unwrapped (Compose f'0 g'1 a) -> f (Unwrapped (h a'))) -> Compose f'0 g'1 a -> f (h a') • In the first argument of ‘(.)’, namely ‘_Wrapping Compose’ In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse • Relevant bindings include traverseCompose :: (a -> f b) -> g a -> f (h a') (bound at Bug.hs:7:1) | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^ Bug.hs:7:19: error: • Couldn't match type ‘g’ with ‘Compose f'0 g'1’ ‘g’ is a rigid type variable bound by the inferred type of traverseCompose :: (a -> f b) -> g a -> f (h a') at Bug.hs:7:1-46 Expected type: (a -> f b) -> g a -> f (h a') Actual type: (a -> f b) -> Compose f'0 g'1 a -> f (h a') • In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse • Relevant bindings include traverseCompose :: (a -> f b) -> g a -> f (h a') (bound at Bug.hs:7:1) | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So for some reason, this bug only seems to pop up when `lens` is installed as a library. I'm stumped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 13:44:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 13:44:36 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.0b62c465f4ef385cbd5269d834dbb803@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Aha! The fault was on my end, as I forgot to put `PolyKinds` into `Lens.hs`. After doing that, I can reproduce the stack overflow with these two files: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Lens where import Data.Coerce import Data.Functor.Compose import Data.Functor.Identity class Profunctor p where dimap :: (a -> b) -> (c -> d) -> p b c -> p a d (#.) :: Coercible c b => (b -> c) -> p a b -> p a c instance Profunctor (->) where dimap ab cd bc = cd . bc . ab {-# INLINE dimap #-} (#.) _ = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b {-# INLINE (#.) #-} type Iso s t a b = forall p f. (Profunctor p, Functor f) => p a (f b) -> p s (f t) type Iso' s a = Iso s s a a iso :: (s -> a) -> (b -> t) -> Iso s t a b iso sa bt = dimap sa (fmap bt) {-# INLINE iso #-} type AnIso s t a b = Exchange a b a (Identity b) -> Exchange a b s (Identity t) data Exchange a b s t = Exchange (s -> a) (b -> t) instance Profunctor (Exchange a b) where dimap f g (Exchange sa bt) = Exchange (sa . f) (g . bt) {-# INLINE dimap #-} (#.) _ = coerce {-# INLINE ( #. ) #-} withIso :: AnIso s t a b -> ((s -> a) -> (b -> t) -> r) -> r withIso ai k = case ai (Exchange id Identity) of Exchange sa bt -> k sa (runIdentity #. bt) {-# INLINE withIso #-} class Wrapped s where type Unwrapped s :: * _Wrapped' :: Iso' s (Unwrapped s) class Wrapped s => Rewrapped (s :: *) (t :: *) class (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (t ~ Compose f' g' a') => Rewrapped (Compose f g a) t instance Wrapped (Compose f g a) where type Unwrapped (Compose f g a) = f (g a) _Wrapped' = iso getCompose Compose _Wrapping :: Rewrapping s t => (Unwrapped s -> s) -> Iso s t (Unwrapped s) (Unwrapped t) _Wrapping _ = _Wrapped {-# INLINE _Wrapping #-} _Wrapped :: Rewrapping s t => Iso s t (Unwrapped s) (Unwrapped t) _Wrapped = withIso _Wrapped' $ \ sa _ -> withIso _Wrapped' $ \ _ bt -> iso sa bt {-# INLINE _Wrapped #-} }}} {{{#!hs module Bug where import Data.Functor.Compose import Lens traverseCompose :: (a -> f b) -> g a -> f (h _) traverseCompose = _Wrapping Compose . traverse }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Lens ( Lens.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:19: error: • Reduction stack overflow; size = 201 When simplifying the following type: g ~ Compose f'0 g'0 Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse | 7 | traverseCompose = _Wrapping Compose . traverse | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So now for the magic question: what fixed this in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 14:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 14:26:55 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.51f3c7b86daeae863c1cc3e8112a5d57@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So now for the magic question: what fixed this in HEAD? You are busy bisecting? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 14:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 14:34:26 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.63e8fc102743587735f5f29265f6e1ca@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed. My hunch is one of Richard's recent commits... I'll report back when I've confirmed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 14:59:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 14:59:44 -0000 Subject: [GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo In-Reply-To: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> References: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> Message-ID: <057.07aa34f696e64f79c8a1c58dd88db071@haskell.org> #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Closing in favour of #14163 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 15:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 15:00:11 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.fc1ea81f686cc813138679a3eec8721a@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, thanks! I've closed #14034 as a dup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 15:34:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 15:34:16 -0000 Subject: [GHC] #14161: Performance Problems on AST Dump In-Reply-To: <049.21b450e0015031856247b17c581564ea@haskell.org> References: <049.21b450e0015031856247b17c581564ea@haskell.org> Message-ID: <064.ec2eff68de6e955968ca99c33276ed13@haskell.org> #14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: dfeuer Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.2.2 => 8.4.1 Comment: I have spoken with h4ck3rm1k3 and he says that he doesn't need this for 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 15:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 15:34:54 -0000 Subject: [GHC] #14159: Decomposition of path sometimes fails In-Reply-To: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> References: <044.6ee1a08b5523ff97e992e21621c93041@haskell.org> Message-ID: <059.e8622d0f5e1ff1dd95281929c5d2acc7@haskell.org> #14159: Decomposition of path sometimes fails ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3891 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 625bea009ed72b8a1ce981acd031799d32e4a944. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 15:45:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 15:45:33 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.f1a3075919355af2cfece2de64183966@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'll admit I've been very much on the fence about this. We have said that we would aim to tighten up the release schedule and one piece of this is to reduce the quantity of non-regression (relative to the last major release, 8.2.1 in this case) bugfixes merged. As alluded to in comment:16, the patch in question is rather large and, while there is nothing particularly challenging about merging it, I do worry that we will lose some amount of moral authority to deny merging other non-critical bugfixes. On the other hand, the patch does significantly improve the clarity of kind errors which I think users will appreciate. I'm going to continue to reflect on this but at the moment I'm leaning towards merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 15:49:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 15:49:22 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.d403ef020335c995f706f3d8cf48451e@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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:D3892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 16:28:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 16:28:21 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.ccf5e3868d78d61f29ed2cfd3b2d4006@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alekzcb): * owner: (none) => alekzcb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 17:40:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 17:40:52 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.5346ecac45e385124ab0cdbfa709d721@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well I'll be... the commit that fixed it was not what I was expecting: 433b80dec1cfef787fc1327a9eada1791b11c12e (`Ensure that insolubles are fully rewritten`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 19:14:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 19:14:09 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family Message-ID: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This rather simple type family, {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators, TypeInType #-} module GenWhoops where import GHC.Generics type family GenComp k (x :: k) (y :: k) :: Ordering where GenComp ((x :+: y) p) ('L1 x) ('L1 y) = GenComp (x p) x y }}} produces the following panic: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170828 for x86_64-unknown-linux): piResultTy k_a1LK[tau:1] p_a1Lz[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:949:35 in ghc:Type }}} This happens with both GHC 8.2.1 and something very close to HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 19:15:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 19:15:46 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.f9416345fa7c26cff185490d2de4c3b2@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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 dfeuer): This really should just be an error, I imagine. It's an (accidental) non- linear pattern where the two types have different kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 19:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 19:55:15 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.71f54e58e174eeb31f64590f501c22f9@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): David also reported seeing this while profiling GHC (#14006). However, I think we should keep this ticket to describe the incompatibility with `forkProcess`. Perhaps comment on #14006 instead. It might be helpful if you could include the `hp` file as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 19:57:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 19:57:48 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe Message-ID: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This definition panics! {{{#!hs {-# LANGUAGE TypeFamilies, TypeInType #-} module Whoops where import Data.Kind type family PComp (k :: j -> Type) (x :: k) :: () }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170828 for x86_64-unknown-linux): repSplitTyConApp_maybe j_aon[sk:1] * * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1123:5 in ghc:Type }}} If I make it a type synonym instead, I get a proper error as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 20:05:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 20:05:44 -0000 Subject: [GHC] #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" Message-ID: <045.933d859277c437bbd0633ba0b0a84f5a@haskell.org> #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Given the following code (full Stack project attached): {{{#!haskell module Foo where import Data.List data MyRecord = MyRecord { f1 :: Maybe String , f2 :: Maybe String , f3 :: Maybe String , f4 :: Maybe String , f5 :: Maybe String , f6 :: Maybe String , f7 :: Maybe String , f8 :: Maybe String , f9 :: Maybe String , f10 :: Maybe String , f11 :: Maybe String , f12 :: Maybe String } getComparisonValue x = ( f1 x , f2 x , f3 x , f4 x , f5 x , f6 x , f7 x , f8 x , f9 x ) doSort = sortOn getComparisonValue }}} The following error results: {{{ $ stack build ghc-bug-0.0.0: build (lib) Preprocessing library ghc-bug-0.0.0... [1 of 1] Compiling Foo ( Foo.hs, .stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0/build/Foo.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_s72t 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: 324566 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package ghc-bug-0.0.0 using: /home/kostmo/.stack/setup-exe-cache/x86_64-linux-nopie/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0 build lib:ghc-bug --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} Generating a tuple from elements of an object for the purpose of sorting is an idiom I have used in Python at times. The original use case in Haskell for me was excluding some fields of the record in the comparison (e.g. `f10`, `f11`, `f12` fields), rather than using a simple `sort` with `deriving Ord` on `MyRecord`. I worked around the issue for now by blanking out the record fields I with to ignore, instead of re-instantiating a tuple of field values: {{{#!haskell getComparisonValue x = x { f10 = Nothing , f11 = Nothing , f12 = Nothing } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 20:10:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 20:10:50 -0000 Subject: [GHC] #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" In-Reply-To: <045.933d859277c437bbd0633ba0b0a84f5a@haskell.org> References: <045.933d859277c437bbd0633ba0b0a84f5a@haskell.org> Message-ID: <060.d07525ed3f6c069ee16f2e9f42e07034@haskell.org> #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kostmo): * Attachment "ghc-bug-demo.tgz" added. minimal test case stack project -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 20:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 20:17:19 -0000 Subject: [GHC] #14173: GHC hangs during type-checking In-Reply-To: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> References: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> Message-ID: <067.e27ba4da459aa632622db9507249274f@haskell.org> #14173: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): With 8.2.1 this fails with, {{{ hi.hs:5:19: error: • Reduction stack overflow; size = 201 When simplifying the following type: g ~ Compose f'0 g'0 Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: _Wrapping Compose . traverse In an equation for ‘traverseCompose’: traverseCompose = _Wrapping Compose . traverse }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 21:19:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 21:19:19 -0000 Subject: [GHC] #14173: GHC hangs during type-checking In-Reply-To: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> References: <052.51a63d5f837fa2638f7abb48855d43d8@haskell.org> Message-ID: <067.71c5c0d25bff2d38029a5283941c9466@haskell.org> #14173: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14172 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14172 Comment: Hm, this seems to have been submitted twice somehow. In any case, closing as a duplicate of #14172. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 21:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 21:31:10 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.b918264630fdd675c9e6270e87fa5ce1@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13910 Comment: On HEAD, this gives a slightly different panic: {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170818: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Whoops ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170818 for x86_64-unknown-linux): getRuntimeRep j_a1tG[sk:1] :: k_a1tJ[tau:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1142:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1982:18 in ghc:Type }}} This is a characteristic that it shares with the program in #13910. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 21:33:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 21:33:06 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.a4a4dcc3105f97c5304f9df98e06e4fe@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13877, #14038 => #13877, #14038, #14175 Comment: See #14175 for a much simpler program that gives the same two panics on GHC 8.2.1/HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 21:41:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 21:41:53 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.7c0f0eea1923335ead5ec982362f16cf@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Is anyone still pursuing this? I was just tossing the idea in my head of proposing multiple block arguments akin to {{{ foo • one complex argument • second complex argument even on multiple lines • third complex argument }}} (with maybe not precisely this syntax), but if we had `ArgumentDo` I could smiply write, as was pointed out in [https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#Multipleblockarguments The wiki proposal], {{{ foo do one complex argument do second complex argument even on multiple lines do third complex argument }}} and I would have no need for a separate proposal… -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 22:00:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 22:00:46 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.5cbc17cd10118d9635fd0feb187fffad@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * priority: normal => highest Comment: This sounds quite bad. Furthermore, it seems that `check#` has absolutely no test coverage. I suspect this is due to our treatment of STM in the demand analyser; `x` in the above program ends up looking like this after strictness analysis, {{{#!hs x_s2KO :: E -> State# RealWorld -> (# State# RealWorld, () #) x_s2KO = \ (e_a2hN [Dmd=] :: E) (eta_B1 [Dmd=] :: State# RealWorld) -> atomically# @ () (\ (eta_a2K4 [Dmd=, OS=OneShot] :: State# RealWorld) -> case catchRetry# @ () (\ (s_a2K5 [Dmd=, OS=OneShot] :: State# RealWorld) -> case e_a2hN of { E ds_d2EV [Dmd=] ds_d2EW [Dmd=] ds_d2EX [Dmd=] -> case ds_d2EX of { GHC.Conc.Sync.TVar tvar#_a2JR [Dmd=] -> case readTVar# @ RealWorld @ [Int] tvar#_a2JR s_a2K5 of { (# ipv_a2JG [Dmd=], ipv1_a2JH [Dmd=] #) -> retry# @ () ipv_a2JG } } }) GHC.Conc.Sync.always2 eta_a2K4 of { (# ipv_a2Kj [Dmd=], ipv1_a2Kk [Dmd=] #) -> case check# @ () (\ (s_a2Ki [Dmd=] :: State# RealWorld) -> case e_a2hN of { E ds_d2EV [Dmd=] ds_d2EW [Dmd=] ds_d2EX [Dmd=] -> case ds_d2EX of { GHC.Conc.Sync.TVar tvar#_a2JR [Dmd=] -> case readTVar# @ RealWorld @ [Int] tvar#_a2JR s_a2Ki of { (# ipv_a2JG [Dmd=], ipv1_a2JH [Dmd=] #) -> (# ipv_a2JG, GHC.Tuple.() #) } } }) ipv_a2Kj of s'_a2Kv [Dmd=] { __DEFAULT -> (# s'_a2Kv, GHC.Tuple.() #) } }) eta_B1 }}} Which then leads us to conclude that the failure in `installSanityChecks` is redundant. Concerningly, this doesn't seem to be caught by the `-fcatch-bottoms` flag introduced in #13916. I'll try to come back to this tomorrow or after ICFP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 31 22:18:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Aug 2017 22:18:55 -0000 Subject: [GHC] #12502: Reject wrong find utility In-Reply-To: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> References: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> Message-ID: <059.68e993f625ca87080ddfd53ea4bfcbd2@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wanjach): See FP_PROG_FIND in aclocal.m4 -- Ticket URL: GHC The Glasgow Haskell Compiler