Glasgow Haskell Compiler 9.0.1-rc1 now available!

Announcements
#1

The GHC team is very pleased to announce the availability of the first
release candidate of GHC 9.0.1 series. Source and binary distributions are
available at the usual place.

This release candidate comes quite a bit later than expected after
difficulty finding a performance neutral fix for a critical soundness
bug, #17760. See the migration page for details on the solution, particularly
if you are a library maintainer currently using the touch# primop or
Foreign.ForeignPtr.withForeignPtr.

Nevertheless, this release has nevertheless seen a considerable amount of
testing and consequently we hope that this should be the last
pre-release before the final release.

In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new
features:

  • A first cut of the new LinearTypes language extension, allowing use
    of linear function syntax and linear record fields.

  • A new bignum library (ghc-bignum), allowing GHC to be more easily
    used with integer libraries other than GMP.

  • Improvements in code generation, resulting in considerable
    performance improvements in some programs.

  • Improvements in pattern-match checking, allowing more precise
    detection of redundant cases and reduced compilation time.

  • Implementation of the ā€œsimplified subsumptionā€ proposal
    simplifying the type system and paving the way for QuickLook
    impredicativity in GHC 9.2.

  • Implementation of the QualifiedDo extension, allowing more
    convenient overloading of do syntax.

  • Improvements in compilation time.

And many more. See the release notes for a full accounting of the
changes in this release.

As always, do test this release and open tickets for whatever issues you
encounter. To help with this, we will be publishing a blog post
describing use of our new head.hackage infrastructure to ease testing
of larger projects with Hackage dependencies later this week.

26 Likes
GHC 8.10.1-rc1 is now available
#2

Cool to see discourse being used for these announcements!

I have two minor remarks. Firstly, I think this repeat of the word ā€˜neverthelessā€™ is unintended:

Secondly, I notice that this text contains manual newlines which interferes with the automatic line breaking of discourse on smaller devices, such as my smartphone.

2 Likes
#3

ghc-9.0.0.20201227-x86_64-unknown-mingw32-integer-simple.tar.xz seems to missing ghci in /bin.

1 Like
#4

ghc-9.0.0.20201227-x86_64-unknown-mingw32-integer-simple.tar.xz seems to missing ghci in /bin.

Hmm, interesting. Iā€™ll need to investigate.

edit This is being tracked as #19136.

1 Like
#5

In previous versions of GHC for Windows, I had the problem that ghc-pkg couldnā€™t initialize a package database if the path was longer than MAX_PATH (even with the MAX_PATH limitation lifted in Windows 10).

ghc-pkg.exe +RTS -RTS init c://reallly//long//path

It always failed while trying to create the package.cache file, with

openBinaryTempFileWithDefaultPermissions: invalid argument (Invalid argument)

Happily, it seems that with the new ā€“io-manager=native option in 9.0, it works correctly:

ghc-pkg.exe +RTS --io-manager=native -RTS init c://reallly//long//path

(It keeps failing without ā€“io-manager=native.)

Hopefully, this will make Backpack more useable on Windows. Backpack tends to generate really long paths internally and was encountering that limitation of ghc-pkg.

2 Likes
#7

Indeed, the new Windows-native IO manager will improve many things, the file path length limit being one of them.

3 Likes
#8

If youā€™re a Stack user interested in testing out this release candidate, I made a stack.yaml configuration for doing that: https://gist.github.com/tfausak/a7ef9af57a9f0c0099f187cd3d920a87

6 Likes
#9

Thanks a lot for great job !
I thought I could share my first experience, trying to build my (not public) project with ghc-9.0.1-rc1 on windows.

note the missing ghci in tarball (already commented)
some libraries are broken by the new whitespace rules around !, @ et al, in my case hmatrix and regex-base (not too difficult to fix though the error messages are indeed cryptic in hmatrix for example so some research was necessary to trace the error to this change ; warnings could be a good thing when the new rules lead to a different interpretation than before)
my library builds allright after these tweaks, but there is something wrong because compilation of executables using it hangs forever. I havenā€™t been able to figure any possible cause yet.
The first compilations of the library have been real slow (like hours for my 100 dependencies instead of 10mn), the last ones were better, no clue to understand why as well but it might be related to my specific environment (corporate pc with antivirus++).
Looking forward to the final version !

PS: sorry for duplicate post, in case you noticed, I happened to reply to the wrong topic

1 Like
#10

Just to amend my remark on warnings, I discovered there is actually a warning for this but it has to be enabled explicitly (-Woperator-whitespace)

#11

Well, I was wrong, the warning was described in the proposal, but didnā€™t get implemented (should be nice though)

#12

my library builds allright after these tweaks, but there is something wrong because compilation of executables using it hangs forever. I havenā€™t been able to figure any possible cause yet.
The first compilations of the library have been real slow (like hours for my 100 dependencies instead of 10mn), the last ones were better, no clue to understand why as well but it might be related to my specific environment (corporate pc with antivirus++).

Are you still able to reproduce this hang in the final version? If so could you open a ticket on https://gitlab.haskell.org/ghc/ghc?

#13

Hello,

Yes thank you, I can confirm that the problem is solved in the final version, everything is ok but some libraries that I use had to be slightly patched (namely regex-base -I use your fork- and hmatrix) to adapt to changes in whitespace treatment around operators.
Some constraints on base version still have to be bypassed as well for a bunch of libraries.
But this will be corrected in time.

The slowness in build process seems also to be gone.

Thanks again for your great work

Bruno

1 Like