- ghc-devs - Haskell.org

[Haskell] [ANNOUNCE] GHC 9.2.3 released
by Zubin Duggal 27 May '22

27 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. 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, Tweag I/O, Serokell, Equinix, SimSpace, 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.3/docs/html/users_guide/9.2.3-notes.h…

3 4

GHC.X.Hackage and GHC's release cycle
by Ben Gamari 27 May '22

27 May '22

Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

1 0

Type vs Constraint
by Simon Peyton Jones 26 May '22

26 May '22

Dear GHC devs and core libraries committee Can I draw your attention to https://gitlab.haskell.org/ghc/ghc/-/issues/21623 This ticket makes specific proposals for how to move forward on the long-standing, and increasingly painful issue of *whether or not Constraint and Type are equal in GHC's type system*. We'd love to know what you think. Please respond on the ticket. The changes affect only GHC internals, so we aren't planning a GHC proposal, but the ticket is essentially a full proposal anyway. It affects only GHC internals, but there are some users who rely on GHC internals, which is why we are seeking your opinions. Thanks Simon

1 0

9.4 branch build failure on ByteString/Internal.hs
by Shayne Fletcher 24 May '22

24 May '22

i've found for the last couple of weeks, the 9.4 branch fails to build with the following error. is this known? a fix in the works? ``` libraries/bytestring/Data/ByteString/Internal.hs:292:23: error: • Couldn't match type ‘m’ with ‘TH.Q’ ‘m’ is a rigid type variable bound by the type signature for: TH.lift :: forall (m :: * -> *). TH.Quote m => ByteString -> m TH.Exp at libraries/bytestring/Data/ByteString/Internal.hs:292:3-6 Expected type: m TH.Exp Actual type: TH.Q TH.Exp • In the expression: [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In an equation for ‘TH.lift’: TH.lift (BS ptr len) = [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In the instance declaration for ‘TH.Lift ByteString’ • Relevant bindings include lift :: ByteString -> m TH.Exp (bound at libraries/bytestring/Data/ByteString/Internal.hs:292:3) | 292 | lift (BS ptr len) = [| unsafePackLenLiteral |] | ^^^^^^^^^^^^^^^^^^^^^^^^^^... ``` -- Shayne Fletcher

1 1

GHC 9.4.1-alpha2 now available
by Ben Gamari 24 May '22

24 May '22

The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha2 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by Hadrian, it's 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]. We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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 testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-note…

1 0

What to do with gmp wasm fixes
by Cheng Shao 24 May '22

24 May '22

Hi all, The ghc wasm32-wasi build needs to patch gmp. Currently, our working branch uses a fork of gmp-tarballs that includes the patch into the tarball, but at some point we need to upstream it. What's the best way to add these fixes? - Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball build script - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp build process is decoupled from ghc build - Give up gmp completely, only support native bignum for wasm32. Cheers. Cheng

3 3

Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
by Matthew Pickering 24 May '22

24 May '22

Hi all, I will shortly prepare a blog post which describes the situation in more detail for a general audience but for the subscribers here is a summary of the release status. 9.4.1-alpha2: The release is imminent, and fixes a number of packaging issues identified with alpha1. Slightly delayed due to regression involving deb9 toolchains. (Ben) 9.2.3: The release will follow shortly (within 1 week) after the 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin) 9.4.1: The target for the final release is end of July. 9.0.* series: We do not intend to do any more releases in the 9.0.* series. - The 9.2 series is more stable - The 9.2 series does not contain significant breakage (when upgrading from 9.0) - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to 9.2.2 - We do not have capacity to manage 4 active branches. Any thoughts, please reply promptly before I communicate these facts with the community. Best Wishes, Matt

3 3

best way to detect invalid Haddock early?
by Norman Ramsey 23 May '22

23 May '22

I've had some CI failures because of invalid Haddock comments. What is the best way to detect such issues locally, early? I tried setting environment variable GHC_FLAGS to "-Winvalid-haddock", which should have told `./hadrian/ghci` to issue a warning. But for some reason, no warning was issued. What's a good way to detect invalid Haddock before it hits CI? Norman

1 0

gitlab spam
by Bryan 17 May '22

17 May '22

While familiarizing myself with gitlab.haskell.org, I noticed there's a ton of spam users and projects. Does this have any practical effect on any of you? Who (if anyone) is the moderation team that handles abuse reports? While I don't think it's a high-priority concern for myself and I don't intend to address it right now, I'd like to at least know what kind of effect this is having on GHC devs. There have already been 50+ users added today, and a random sample was 100% spam. There are 84,000 users and 1700 projects in the system in total. I assume 90-99% of them are spam. Not really conducive to a balanced diet. -Bryan "eat more veggies" Richter

4 4

ambiguous record field (but not *that* kind of ambiguous record field)
by Richard Eisenberg 16 May '22

16 May '22

Hi all, On a project I'm working on, I wish to declare something like data Rec = MkRec { field :: forall a. SomeConstraint a => ... } where the ... contains no mention of `a`. Even with https://github.com/ghc-proposals/ghc-proposals/pull/448 <https://github.com/ghc-proposals/ghc-proposals/pull/448>, I think there is no way to avoid the ambiguity when setting `field`. Is that correct? If so, what shall we do about it? The natural answer is somehow to write ... MkRec { field @a = ... } ... but that would break significant new syntactic ground. (Maybe it's good new syntactic ground, but it would still be very new.) Thanks, Richard

3 3