- ghc-devs - Haskell.org

Release schedules: 9.6.2 and 9.8.1
by Matthew Pickering 12 May '23

12 May '23

Hi all, * We are preparing the 9.6.2 release to happen within 1-2 weeks. * The proposed 9.8.1 schedule is as follows: Fork Date: June 16th Release Date: Early September Feature patches not in the tree by June 16th will not be included in the release. This is the six-month release cadence which we have proposed to follow. Cheers, Matt

1 0

GHC GitLab change to login: disabling OAuth via GitHub
by Bryan Richter 07 May '23

07 May '23

Hi folks, Spammers have been abusing GitHub OAuth to create accounts on gitlab.haskell.org and post spam. Due to team resources, the only good way to stop spammers right now is to manually approve each new user. GitHub OAuth defeats that by automatically approving new users. So, sadly, I have disabled GitHub OAuth for the time being. If you used it to sign up and have trouble logging in now, one of us admins can help you out. -Bryan

2 2

Contributing packages?
by Dominick Samperi 04 May '23

04 May '23

I just tried to upload a new Haskell package and ran into some difficulties. If I just try to upload, it fails and says I need to contact somebody in the trustees group to be added to the Uploaders group. If I try to upload a package candidate instead, it says Forbidden, No access for this resource. The Uploading packages help page is not very helpful. Also, I have a Hackage account and I can get to the account management page, and generate an auth key, but I don't know what I can do with that. It seems the package candidate feature is the way to go, since direct uploads are irreversible and more difficult to manage. Any tips would be appreciated. Thanks, Dominick

1 0

Build of GHC 9.6 fails when the build directory is not a child of the source directory
by Viktor Dukhovni 30 Apr '23

30 Apr '23

For some time now I'd been unable to build GHC 9.6 from source. The reason turned out to be that my hadrian command-line selected an explicit build directory that was not an immediate child of the source directory (default it seems is "_build"). With the source tree under "$HOME/dev/ghc/", the hardrian command $ hadrian/build -V -V -o"$HOME/dev/buildghc" --docs=no-sphinx binary-dist-dir after building stage0, and running "configure" in libraries/base, reports an error finding HsFFI.h: Reading parameters from $HOME/dev/buildghc/stage1/libraries/base/build/base.buildinfo /usr/bin/cc '-fuse-ld=gold' /tmp/2303653-4.c -o /tmp/2303653-5 '-D__GLASGOW_HASKELL__=906' \ '-Dlinux_BUILD_OS=1' \ '-Dx86_64_BUILD_ARCH=1' \ '-Dlinux_HOST_OS=1' \ '-Dx86_64_HOST_ARCH=1' \ -I$HOME/dev/buildghc/stage1/libraries/base/build/autogen \ -I$HOME/dev/buildghc/stage1/libraries/base/build/include \ -Ilibraries/base/include \ -Ilibraries/base \ -I/usr/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include/ \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include/ \ -I$HOME/dev/buildghc/stage1/inplace/../../..//libraries/ghc-bignum/include \ -I$HOME/dev/buildghc/stage1/libraries/ghc-bignum/build/include \ -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include \ -I$HOME/dev/buildghc/stage1/rts/build/include \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@FFIIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/inplace/../../..//rts/@LibdwIncludeDir@' \ '-I$HOME/dev/buildghc/stage1/rts/build/@LibdwIncludeDir@' \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-bignum/build \ -L$HOME/dev/buildghc/stage1/inplace/../libraries/ghc-prim/build \ -L$HOME/dev/buildghc/stage1/inplace/../rts/build -iquote \ $HOME/dev/ghc/libraries/base \ '-fuse-ld=gold' There are two issues to note here: - "hadrian" fails to substitute @FFIIncludeDir@ and @LibdwIncludeDir@. This used to be handled by "configure", but the job of turning "rts.cabal.in" into "rts.cabal" seems to have been reassigned to "hadrian". - With the build output directory a sibling rather than a child of the source tree, the path to "rts/include" is not constructed correctly. The path: -I$HOME/dev/buildghc/stage1/inplace/../../..//rts/include should have been: -I$HOME/dev/buildghc/stage1/inplace/../../../ghc/rts/include Switching to the default path proved to be a viable work-around, but perhaps other choices should also work. -- Viktor.

2 2

does llvm 16 work with ghc 9.6.1 ?
by George Colpitts 25 Apr '23

25 Apr '23

Hi Does anybody know if llvm 16 works with ghc 9.6.1 ? Thanks George

2 4

GHC 9.6.1 rejects previously working code
by Harendra Kumar 25 Apr '23

25 Apr '23

The following code compiles with older compilers but does not compile with GHC 9.6.1: {-# LANGUAGE KindSignatures #-} module A () where import Control.Monad.IO.Class import Control.Monad.Trans.Class data T (m :: * -> *) a = T instance Functor (T m) where fmap f T = undefined instance Applicative (T m) where pure = undefined (<*>) = undefined instance MonadIO m => Monad (T m) where return = pure (>>=) = undefined instance MonadTrans T where lift = undefined It fails with the following error: xx.hs:20:10: error: [GHC-39999] • Could not deduce ‘MonadIO m’ arising from the head of a quantified constraint arising from the superclasses of an instance declaration from the context: Monad m bound by a quantified context at xx.hs:20:10-21 Possible fix: add (MonadIO m) to the context of a quantified context • In the instance declaration for ‘MonadTrans T’ | 20 | instance MonadTrans T where | ^^^^^^^^^^^^ What is the correct resolution for this? -harendra

4 4

[Haskell] [ANNOUNCE] GHC 9.4.5 released
by Zubin Duggal 18 Apr '23

18 Apr '23

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5). Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include: * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725). * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528) * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680) * Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743) * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and many 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.4.5/docs/html/users_guide/9.4.5-notes.…

1 0

Performance of small allocations via prim ops
by Harendra Kumar 12 Apr '23

12 Apr '23

I was looking at the RTS code for allocating small objects via prim ops e.g. newByteArray# . The code looks like: stg_newByteArrayzh ( W_ n ) { MAYBE_GC_N(stg_newByteArrayzh, n); payload_words = ROUNDUP_BYTES_TO_WDS(n); words = BYTES_TO_WDS(SIZEOF_StgArrBytes) + payload_words; ("ptr" p) = ccall allocateMightFail(MyCapability() "ptr", words); We are making a foreign call here (ccall). I am wondering how much overhead a ccall adds? I guess it may have to save and restore registers. Would it be better to do the fast path case of allocating small objects from the nursery using cmm code like in stg_gc_noregs? -harendra

5 12

[ANNOUNCE] GHC 9.6.1 is now available
by Ben Gamari 02 Apr '23

02 Apr '23

The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 includes: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively. Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC's first step towards supporting web targets, we are very excited to have this release out the door! Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html

3 2

GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue
by Martin Baulig 30 Mar '23

30 Mar '23

Hello, I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor the GHC 9.2.7 binary packages from GHCUP work anymore. There are two issues - and I wrote a detailed article about my investigation on Medium: https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" into > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" Otherwise, this will break when both ccArgs and ldFlags are non-empty: > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" Unfortunately, this is not quite it just yet. The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always invoking hsc2hs with an explicit --cc= argument. Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last name in lowercase, baulig. Looking forward to hear back from you, Martin

2 3