- ghc-devs - Haskell.org

[Haskell] [ANNOUNCE] GHC 9.2.5 released
by Zubin Duggal 07 Nov '22

07 Nov '22

The GHC developers are very happy to at announce the availability of GHC 9.2.5. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.5). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_5.html Blog Post: https://www.haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.4. These include: * Code generation issues in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282, #21964) * Fixes for a number of issues with the simplifier leading to core lint errors and suboptimal performance (#21694, #21755, #22114) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A runtime system bug where creating empty mutable arrays resulted in a crash (#21962) - ... and a few more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.5/docs/html/users_guide/9.2.5-notes.…

1 0

Is Prep supposed to keep thing in (reverse) dependency order?
by ÉRDI Gergő 04 Nov '22

04 Nov '22

Hi, I was under the impression that the Prep'd Core is still in reverse dependency order, i.e. if definition A refers to intra-module definition B, then A's binding will always be preceding B's binding. I've been exploiting this (hopefully not made-up and accidental!) property in my work so far. However, for the following input: ``` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` <Co:32>) x1 } in (\ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` <Co:55>) x2) `cast` <Co:22>) `cast` <Co:148>) `cast` <Co:125>) ``` I am getting the following output from Prep: ``` sat_s2iCp :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b sat_s2iCp = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` <Co:32>) x1 } in let { sat_s2iCo :: CSASource -> Currency -> Fun '[String] b sat_s2iCo = \ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` <Co:55>) x2) `cast` <Co:22>) } in sat_s2iCo `cast` <Co:148>) `cast` <Co:125> $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = \ (@a) (@b) (eta_B0 :: a -> b) (eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) -> sat_s2iCp @a @b eta_B0 eta_B1 ``` Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to `sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of `$s$fFunctorFun_$sfmap`. Is this expected, for some reason, or is this a GHC bug? If the latter, I'm happy to file a ticket but I can't promise an actual end-to-end compilable reproducer...

2 1

[ANNOUNCE] GHC 9.4.3 is now available
by Ben Gamari 03 Nov '22

03 Nov '22

The GHC developers are happy to announce the availability of GHC 9.4.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.3 This release is primarily a bugfix release addressing a few issues found in 9.4.2. These include: * An issue where recursively calls could be speculatively evaluated, resulting in non-termination (#20836) * A code generation issue in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282) * A crash on Darwin when running executables compiled with IPE support (#22080) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A bug in the `process` library where file handles specified as `NoStream` would still be usable in the child (process#251) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a ticket if you see anything amiss. Happy Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

Reducing all type family applications as far as possible
by ÉRDI Gergő 28 Oct '22

28 Oct '22

Hi, Is there a way to have GHC reduce all (reducable) type familiy applications? For example, if I have ``` type family Id x where Id x = x foo :: Bool -> Id Bool foo x = x ``` then I would like the `Id` of `foo` to have type `Bool -> Bool`, and the generated Core should be either `foo = \x -> x` or, if that's asking for too much, at least something like `foo = \x -> x |> (somePossiblyOvercomplicatedCoercion :: Bool ~ Bool)`. Is there already some functionality for this in GHC? If not, how messy would it be to implement it as a separate `CoreProgram` transformation just after desugaring? It'd need to be immediately after desugaring because I would like e.g. the specialiser to already specialise in terms of these reduced types. Thanks, Gergo

1 0

Exact Print Annotations Next Steps
by Alan & Kim Zimmerman 20 Oct '22

20 Oct '22

I have put down some thoughts about simplifying the exact print annotations, prior to extending them to support printing the `RenamedSource`. See https://gitlab.haskell.org/ghc/ghc/-/issues/22319 Alan

1 0

GHC.Pack deprecation process: Step 1
by Hécate 18 Oct '22

18 Oct '22

Hi everyone, As discussed earlier this year¹, the deprecation process for GHC.Pack starts with the 9.6.1 milestone². ¹ https://gitlab.haskell.org/ghc/ghc/-/issues/21461 ² https://gitlab.haskell.org/ghc/ghc/-/issues/21541 Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

Release Timelines
by Matthew Pickering 18 Oct '22

18 Oct '22

Hi all, Three releases are currently cooking. * 9.2.5 (End of October) - Fixes to performance regressions introduced in 9.2.4. - Fix to interface file determinism - Critical correctness fix for AArch64 code generation * 9.4.3 (End of October) - Critical correctness fix for AArch64 code generation - Fixes to performance regressions introduced in 9.4.2. - Fix to interface file determinism * 9.6.1 (Early 2023) - Branch will be taken in early november. Cheers, Matt

3 2

9.6.1 branch date - Wednesday 7th Nov
by Matthew Pickering 18 Oct '22

18 Oct '22

Hi all, In order to keep up the 6-month release cadence it is nearly time to take the branch for the 9.6.1 release. The date the branch will be taken is Wednesday 7th Nov. Please reply to this email if there are any in-flight patches which should be included in the 9.6 release. Cheers, Matt

1 0

Missing class op rules when using API
by Erdi, Gergo 18 Oct '22

18 Oct '22

PUBLIC Hi, I'm trying to compile the following two modules: ``` {-# LANGUAGE NoImplicitPrelude #-} module MiniMonad where class Functor f where fmap :: (a -> b) -> f a -> f b class (Functor f) => Applicative f where pure :: a -> f a class (Applicative m) => Monad m where return :: a -> m a return = pure (>>=) :: m a -> (a -> m b) -> m b infixl 1 >>= ``` ``` {-# LANGUAGE NoImplicitPrelude #-} module SpecMain where import MiniMonad data Identity a = MkIdentity a instance Functor Identity where fmap f (MkIdentity x) = MkIdentity (f x) instance Applicative Identity where pure x = MkIdentity x instance Monad Identity where run :: Identity a -> a run (MkIdentity x) = x foo :: () foo = run (return ()) ``` If I compile these from the CLI, I see three rules firing: ``` ./_build/stage1/bin/ghc -debug -fforce-recomp -dno-typeable-binds input/SpecMain.hs -iinput -O0 -ddump-rule-rewrites -dsuppress-all ``` ``` [1 of 2] Compiling MiniMonad ( input/MiniMonad.hs, input/MiniMonad.o ) [2 of 2] Compiling SpecMain ( input/SpecMain.hs, input/SpecMain.o ) tc_iface_decl/2 Monad input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op $p1Monad Module: (BUILTIN) Before: MiniMonad.$p1Monad TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: SpecMain.$fApplicativeIdentity Cont: StrictArg MiniMonad.pure ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op pure Module: (BUILTIN) Before: MiniMonad.pure TyArg SpecMain.Identity ValArg SpecMain.$fApplicativeIdentity After: $cpure_aw8 Cont: ApplyToTy a_avS Stop[RhsCtxt(Recursive)] a_avS -> SpecMain.Identity a_avS Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_avP Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () ``` However, if I try this via the API (see attached `main.hs`), then only `Class op return` fires: ``` Processing module MiniMonad Processing module SpecMain input/SpecMain.hs:14:10: warning: [-Wmissing-methods] * No explicit implementation for '>>=' * In the instance declaration for 'Monad Identity' | 14 | instance Monad Identity where | ^^^^^^^^^^^^^^ Rule fired Rule: Class op return Module: (BUILTIN) Before: MiniMonad.return TyArg SpecMain.Identity ValArg SpecMain.$fMonadIdentity After: $creturn_aqm Cont: ApplyToTy () ApplyToVal nodup hole () -> SpecMain.Identity () GHC.Tuple.Prim.() Select nodup wild_X1 Stop[RhsCtxt(NonRecursive)] () All done. ``` This of course leads to much worse code further downstream (and is catastrophic for my use case where I rely on extensive specialisation). Why is that? What is missing from my `main.hs` that only one of the three method rules is correctly used when compiling the second module? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 1

Serious bug in GHC 9.4 on basic math on aarch64
by Ian-Woo Kim 14 Oct '22

14 Oct '22

Hi, We found a reproducible error with a simple math test (div/mod) on aarch64. (on linux, on macos), so we want to call for attention on this. https://gitlab.haskell.org/ghc/ghc/-/issues/22282 This was originally caught by this issue: https://github.com/haskell-foundation/foundation/issues/571 Thank you! Ian-Woo Kim Mercury Technologies

4 4