- ghc-devs - Haskell.org

[ANNOUNCE] GHC 9.4.1-rc1 is now available
by Ben Gamari 02 Aug '22

02 Aug '22

The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] 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 provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - 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. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... 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 our 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]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the 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 testing, - Ben [downloads.haskell.org] https://downloads.haskell.org/ghc/9.4.1-rc1/ [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… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.h…

5 11

[Haskell] [ANNOUNCE] GHC 9.2.4 released
by Zubin Duggal 29 Jul '22

29 Jul '22

The GHC developers are very happy to at announce the availability of GHC 9.2.4. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.4). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html Blog Post: https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html This release will include: - The new `DeepSubsumption` language extension which reverses the effects of the [Simplified Subsumption Proposal] introduced in GHC 9.0. This is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and eases migration for users who depended on this feature. This extension is enabled by default with the `Haskell2010` and `Haskell98` languages but disabled with the `GHC2021` language originally introduced in GHC 9.2.1. See the [Deep Subsumption Proposal] for more details. - Fixes for segfaults that may arise due to a bug in the implementation of the `keepAlive#` primop. This may regress performance for certain programs which use this primop or functions which use the primop, such as `withForeignPtr`. These regressions are mostly small, but can be larger in certain edge cases. Judicious use of `unsafeWithForeignPtr` when its argument is known not to statically diverge can mitigate these in many cases. It is our judgment that the critical correctness issues justify the regression in performance and that it is important to get a release out with the fix while we work on a better approach which will improve performance for future releases (#21708). We have a [wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) that tracks possible solutions to this problem, and Ben wrote a [blog post](https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) detailing the introduction of the `keepAlive#` primop and its history. - Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685). - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885). - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). - ... and much 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, 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.4/docs/users_guide/9.2.4-notes.html [Simplified Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… [Deep Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-d…

3 2

Test suite
by Simon Peyton Jones 28 Jul '22

28 Jul '22

Doing *hadrian/build test* takes absolutely ages. It seems that it is building haddock, running haddock, building check_exact, and other things. Eg right now it is doing Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 more) => _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock But I didn't ask to do Haddock. I just wanted to run the testsuite. How can I do that? I would prefer never to build haddock. Thanks Simon

3 3

Wildcards in type synonyms
by ÉRDI Gergő 26 Jul '22

26 Jul '22

Hi, I'd like to implement type synonyms containing wildcards. The idea is that if you have `type MySyn a = MyType a _ Int`, then during typechecking, every occurrence of `MySyn T` would be expanded into `MyType T w123 Int`, with a fresh type (meta)variable `w123`. One worrying thing I noticed in my initial exploration of the GHC codebase is that the Core representation of `Type`s can still contain type synonym occurrences. And this doesn't seem like just an artefact of sharing the `Type` representation with `TcType`, since the `coreView` function also has code to look through type synonyms. What is the reason for this? I would have expected type synonyms to be only relevant during typechecking, and then fully resolved in the elaborated Core output. If that were the case, then a new version of `expand_syn` could live in `TcM` and take care of making these fresh metavariables. Beside this concrete question, taking a step back, I would also like to hear from people who know their way around this part of GHC, what they think about this and how they'd approach implementing it. Thanks, Gergo

5 14

GHC development asks too much of the host system
by Hécate 21 Jul '22

21 Jul '22

Hello ghc-devs, I hadn't made significant contributions to the GHC code base in a while, until a few days ago, where I discovered that my computer wasn't able to sustain running the test suite, nor handle HLS well. Whether it is my OS automatically killing the process due to oom-killer or just the fact that I don't have a war machine, I find it too bad and I'm frankly discouraged. This is not the first time such feedback emerges, as the documentation task force for the base library was unable to properly onboard some people from third-world countries who do not have access to hardware we'd consider "standard" in western Europe or some parts of North America. Or at least "standard" until even my standard stuff didn't cut it anymore. So yeah, I'll stay around but I'm afraid I'm going to have to focus on projects for which the feedback loop is not on the scale of hours , as this is a hobby project. Hope this will open some eyes. Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

10 19

Hadrian problem
by Simon Peyton Jones 12 Jul '22

12 Jul '22

I'm in a GHC tree, built with Hadrian, I'm getting this red problem. But compilation has got way past compiling base. why is it looking in my .ghc/... directory? It should be looking in my build tree. Simon bash$ ~/code/HEAD-1/_build/ghc-stage1 -c Foo.hs Loaded package environment from /home/simonpj/.ghc/x86_64-linux-9.5.20220628/environments/default <command line>: cannot satisfy -package-id base-4.17.0.0 (use -v for more information) bash$ cat ~/code/HEAD-1/_build/ghc-stage1 "/home/simonpj/code/HEAD-1/_build/stage0/bin/ghc" "-no-global-package-db" "-package-db /home/simonpj/code/HEAD-1/_build/stage1/lib/package.conf.d" "$@"

3 2

Tracking intermittently failing CI jobs
by Bryan 12 Jul '22

12 Jul '22

Hi all, I'd like to get some data on weird CI failures. Before clicking "retry" on a spurious failure, please paste the url for your job into the spreadsheet you'll find linked at https://gitlab.haskell.org/ghc/ghc/-/issues/21591. Sorry for the slight misdirection. I wanted the spreadsheet to be world-writable, which means I don't want its url floating around in too many places. Maybe you can bookmark it if CI is causing you too much trouble. :) -Bryan

2 1

Hadrian
by Simon Peyton Jones 11 Jul '22

11 Jul '22

I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say

3 7

Re: 9.4.1 Final Call
by Ryan Scott 05 Jul '22

05 Jul '22

One thing that wasn't included in the list but arguably should be is #21618 (Loading libc++ in ghci results in segfaults). As far as I am aware, this renders GHC 9.4 unusable on Windows for libraries that link against C++. (Or, at the very least, I haven't figured out a way to make it work.) Best, Ryan S.

1 0

9.4.1 Final Call
by Matthew Pickering 05 Jul '22

05 Jul '22

Hello all, This is the final call for patches which need to be included in 9.4.1. The status of which I do not know the answer: * GHC 9.4 infinite loop in typechecker - #21530 (@simonpj, @rae) ? To my knowledge the remaining unfinished work list is: * Resolve static linking issues with text-2.0 - #21787 (Unresolved) (Matt/Ben/Zubin/Tamar/Andreww) * CAF reachability bug with -fprof-late - !7797 (WIP) (Andreas/Ben) * XMonad segfault - #21708 (WIP) (Ben/Andreas) * HIE File Fixes - !7888 (landing) (Zubin) * template-haskell-2.19.0.0 depends on filepath - !8516 (landing) (Matt) * Module loops and multiple home units leads to a panic - !8573 (nearly ready to land) (Matt) * extendMG leaks memory - #21816 (Zubin/Matt) To my knowledge, the following are not making it into 9.4.1.. but are not critical to revert: * Tidy up withDict and friends - #21568 Looking like a great release. Matt

2 1