- ghc-devs - Haskell.org

stack exec -- pacman broken
by Shayne Fletcher 11 May '22

11 May '22

this isn't exactly a GHC issue but perhaps someone knows how to get it resolved? (suspecting commercial/stack i've raised [this issue]( https://github.com/commercialhaskell/stack/issues/5732) there). tl;dr `stack exec -- pacman -S ...` like commands required for building GHC on windows are broken and have been for sometime ghc-lib CI runs this command on windows, ``` stack --resolver lts-18.23 exec -- pacman -S autoconf automake-wrapper make patch python tar mintty --noconfirm ``` this normally works ok but as of today, ``` warning: database file for 'clang32' does not exist (use '-Sy' to download) warning: mintty-1~3.6.0-1 is up to date -- reinstalling error: failed to prepare transaction (could not find database) ``` in another project (ghc-lib-parser-ex), a similar command (different compiler version/stack yaml) has been producing the following reliably long enough that i'm sorry to say i just gave up testing it windows. ``` :: File /var/cache/pacman/pkg/automake1.9-1.9.6-3-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: automake1.10: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: automake1.11: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: automake1.12: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: automake1.13: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: automake1.14: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: automake1.15: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust :: File /var/cache/pacman/pkg/automake1.10-1.10.3-4-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] :: File /var/cache/pacman/pkg/automake1.11-1.11.6-4-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] :: File /var/cache/pacman/pkg/automake1.12-1.12.6-4-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] :: File /var/cache/pacman/pkg/automake1.13-1.13.4-5-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] :: File /var/cache/pacman/pkg/automake1.14-1.14.1-4-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: automake1.16: signature from "David Macek <david.macek.0(a)gmail.com>" is unknown trust error: failed to commit transaction (invalid or corrupted package) :: File /var/cache/pacman/pkg/automake1.15-1.15.1-2-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] :: File /var/cache/pacman/pkg/automake1.16-1.16.3-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] Errors occurred, no packages were upgraded. ``` -- Shayne Fletcher

1 1

Gitlab problem
by Simon Peyton Jones 10 May '22

10 May '22

Friends I am abruptly unable to push or pull to the GHC repo. E.g. 'git fetch' just hangs. Yet ssh git(a)gitlab.haskell.org seems to succeed with PTY allocation request failed on channel 0 Welcome to GitLab, @simonpj! Connection to gitlab.haskell.org closed. How could I debug this? I'm on WSL. My network appears to be fine. Thanks. I'm totally stalled. Simon

2 2

Deprecation process for GHC.Pack
by Hécate 09 May '22

09 May '22

Hello fellow devs, Just an email to signal the start of the deprecation process of GHC.Pack, with the three-releases cycle: 1. By prose (GHC 9.6) (#21541 <https://gitlab.haskell.org/ghc/ghc/-/issues/21541>) 2. By warning (GHC 9.8) (#21540 <https://gitlab.haskell.org/ghc/ghc/-/issues/21540>) 3. By error (GHC 9.10) (#21536 <https://gitlab.haskell.org/ghc/ghc/-/issues/21536>) You can read more about the whole thing here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461 Cheers, have a nice week! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD

1 0

Specialising NOINLINE functions
by Simon Peyton Jones 09 May '22

09 May '22

Dear devs At the moment the INLINEABLE pragma means "capture my right-hand side, regardless of how big it is, so that it can be type-class-specialised, including in other modules". But it *also *says "feel free to inline me". Some users (eg Gergo) want to say NOINLINE on some functions. But for these they'd still like to generate type-class-specialised versions. After all, if we aren't going to inline them, specialising is the next best thing. But we have no way to say both "specialise me" and "don't inline me", because you can't say both INLINEABLE and NOINLINE. (That would look silly.) I think we should probably just bite the bullet and add a SPECIALISABLE pragma, *orthogonal to INLINE/NOINLNE*, which say "capture my right-hand side, regardless of how big it is, so that it can be type-class-specialised, including in other modules". It behaves exactly like INLINEABLE except that you can specify it along with INLINE/NOINLINE. Any thoughts? Do you think this needs a GHC proposal? See #21036 <https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930> Simon

5 6

[ANNOUNCE] GHC 9.2.2 is not available
by Ben Gamari 05 May '22

05 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, 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. Finally, thank you to Microsoft Research, 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. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h…

3 5

"Modularizing GHC" paper
by Sylvain Henry 04 May '22

04 May '22

Hi GHC devs, With John Ericson and Jeffrey Young we wrote a paper about the modularization of GHC. It gives a global picture for the refactorings we have been performing (c.f. e.g. #17957) and some potential future ones. Announce blog post: https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf Discussion on Reddit: https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/ We welcome any feedback, here or on reddit. Cheers, Sylvain

4 3

Our ambitions for GHC 9.6
by Hécate 03 May '22

03 May '22

Hi everyone, With 9.4 just around the corner, I am gathering broad ambitions for user-facing improvements that we wish to ship for GHC 9.6. At this moment, the new JavaScript and WebAssembly backends have been listed, but I'd be very interested to add more content. This document is especially for public communication regarding our activities. Since these are ambitions, it's not a hard deadline, nor does it imply dreadful consequences for the people who didn't manage to have their improvements shipped in time. I'm really excited for 9.4 and all the good stuff we're going to have in the future of GHC! Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 1

Extending call_args when specialising DFuns
by ÉRDI Gergő 02 May '22

02 May '22

Hi, In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC extends the call_args with dummy UnspecArg elements, to make it trivially fully saturated. There's a Note describing this behaviour: """ Note [Specialising DFuns] ~~~~~~~~~~~~~~~~~~~~~~~~~ DFuns have a special sort of unfolding (DFunUnfolding), and these are hard to specialise a DFunUnfolding to give another DFunUnfolding unless the DFun is fully applied (#18120). So, in the case of DFunIds we simply extend the CallKey with trailing UnspecArgs, so we'll generate a rule that completely saturates the DFun. There is an ASSERT that checks this, in the DFunUnfolding case of GHC.Core.Unfold.specUnfolding. """ (note that the reference in the second paragraph is stale; it should point to GHC.Core.Unfold.Make.specUnfolding) So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm missing something, a DFun can't have any term parameters, only type and dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't break validate, which suggests that it is hard to even exercise this code path. I'm bringing this up because on the GHC fork that I'm working on, I have the specializer do more than vanilla GHC: on my fork, specialization of higher-kinded type variables is just as useful as specializing dictionaries. With that change, I can get GHC panics when padding DFun calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is a very weak argument for this change; what I'm looking for here is a discussion on what the padding should be, in vanilla GHC, from first principles. Thanks, Gergo

2 2

GHC 9.4.1-alpha1 now available
by Ben Gamari 02 May '22

02 May '22

The GHC developers are happy to announce the availability of the first 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-alpha1 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. - ... and much more 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

2 1

Documenting primtypes, round 1: ByteArray# and Array#
by Hécate 30 Apr '22

30 Apr '22

Hi everyone, With the sunny days back in this hemisphere, so do the documentation MRs. I have two primtypes for which I'd like some help / review / interesting information: * ByteArray#: This is mostly done, you can observe the current rendered draft documentation here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8067#note_425560 Please note that the free-floating "Byte Arrays" section of documentation cannot be exported or re-exported by GHC.Exts, so we're pretty much left with what's in the types' documentation; * Array#: The ticket is here: https://gitlab.haskell.org/ghc/ghc/-/issues/21462 State of things: In terms of documentation, we have no documentation. Some stuff can be inferred from the SmallArray# haddocks but I doubt that every property / interesting usage / pitfall can be reasonable derived from putting ¬ at the beginning of the SmallArray# documentation. Now, on an unrelated note, I'm also wondering about the fate of GHC.Pack, for a number of reasons. You will find the ticket here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461. My thanks to everyone who's helped me so far, with a special mention to bodigrim and koz ross. Cheers -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0