Upgrade GHC to 9.2

[aspiwack]

Part of #389.

---

This PR originally fixed the tasty-hedgehog deprecation warning. But because it turned out to that GHC 9.2 is having problem with our PR, I extracted this bit in #415.

I'll rebase on master as soon as #415 is merged to clear up the tasty-hedgehog bits.

---

Edit: I wanted to only make a draft PR, but I misclicked. I don't think that
I can convert it back. I don't know how anyway. I don't want to merge quite
yet, as there is a bug related to stack ghci which causes an anomaly in GHC:

$ stack ghci
Stack has not been tested with GHC versions above 9.0, and using 9.2.2, this may fail
Stack has not been tested with Cabal versions above 3.4, but version 3.6.3.0 was found, this may fail
Configuring GHCi with the following packages: linear-base
GHCi, version 9.2.2: https://www.haskell.org/ghc/  :? for help
[ 1 of 86] Compiling Data.Arity.Linear.Internal ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Arity/Linear/Internal.hs, interpreted )
[ 2 of 86] Compiling Data.Arity.Linear ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Arity/Linear.hs, interpreted )
[ 3 of 86] Compiling Data.Bool.Linear ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Bool/Linear.hs, interpreted )
[ 4 of 86] Compiling Prelude.Linear.GenericUtil ( /home/aspiwack/projects/tweag/linear-base/master/src/Prelude/Linear/GenericUtil.hs, interpreted )
[ 5 of 86] Compiling Data.Unrestricted.Linear.Internal.Ur ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Unrestricted/Linear/Internal/Ur.hs, interpreted )
[ 6 of 86] Compiling Prelude.Linear.Generically ( /home/aspiwack/projects/tweag/linear-base/master/src/Prelude/Linear/Generically.hs, interpreted )
[ 7 of 86] Compiling Prelude.Linear.Internal ( /home/aspiwack/projects/tweag/linear-base/master/src/Prelude/Linear/Internal.hs, interpreted )
[ 8 of 86] Compiling Data.Replicator.Linear.Internal.ReplicationStream ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Replicator/Linear/Internal/ReplicationStream.hs, interpreted )
[ 9 of 86] Compiling Data.Replicator.Linear.Internal ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Replicator/Linear/Internal.hs, interpreted )
[10 of 86] Compiling Prelude.Linear.Unsatisfiable ( /home/aspiwack/projects/tweag/linear-base/master/src/Prelude/Linear/Unsatisfiable.hs, interpreted )
[11 of 86] Compiling Unsafe.Linear    ( /home/aspiwack/projects/tweag/linear-base/master/src/Unsafe/Linear.hs, interpreted )
[12 of 86] Compiling Data.Unrestricted.Linear.Internal.Consumable ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Unrestricted/Linear/Internal/Consumable.hs, interpreted )
[13 of 86] Compiling Data.Unrestricted.Linear.Internal.Dupable ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Unrestricted/Linear/Internal/Dupable.hs, interpreted )
[14 of 86] Compiling Data.V.Linear.Internal ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/V/Linear/Internal.hs, interpreted )
[15 of 86] Compiling Data.Tuple.Linear ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Tuple/Linear.hs, interpreted )
[16 of 86] Compiling Data.Monoid.Linear.Internal.Semigroup ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Monoid/Linear/Internal/Semigroup.hs, interpreted )
[17 of 86] Compiling Data.Monoid.Linear.Internal.Monoid ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Monoid/Linear/Internal/Monoid.hs, interpreted )
[18 of 86] Compiling Data.Monoid.Linear ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Monoid/Linear.hs, interpreted )
[19 of 86] Compiling Data.Functor.Linear.Internal.Functor ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Functor/Linear/Internal/Functor.hs, interpreted )
[20 of 86] Compiling Data.Functor.Linear.Internal.Applicative ( /home/aspiwack/projects/tweag/linear-base/master/src/Data/Functor/Linear/Internal/Applicative.hs, interpreted )

/home/aspiwack/projects/tweag/linear-base/master/src/Data/Functor/Linear/Internal/Applicative.hs:101:18: error:ghc: panic! (the 'impossible' happened)
  (GHC version 9.2.2:
	No skolem info:
  [k_ad3j]
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in ghc:GHC.Utils.Panic
        pprPanic, called at compiler/GHC/Tc/Errors.hs:2912:17 in ghc:GHC.Tc.Errors

Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug


<no location info>: error:
    Could not load module ‘Control.Functor.Linear’
    It is a member of the hidden package ‘linear-base-0.2.0’.
    You can run ‘:set -package linear-base’ to expose it.
    (Note: this unloads all the modules in the current scope.)
Loaded GHCi configuration from /tmp/haskell-stack-ghci/eea5bf06/ghci-script

I haven't investigated this problem yet, and I want to know a bit more before we merge

---

Another problem that I noticed is that the format script cannot install Ormolu anymore (due to an upper bound somewher)

• Investigate the anomaly
• Fix Ormolu installation in the format script

[aspiwack]

Solving the Ormolu problem took a negative number of lines. Convenient.

[aspiwack]

The panic happens on the library. It's probably not caused by the clever setup that stack ghci does to load all your modules across units.

It doesn't happen with stack build though. This is quite puzzling for something that appear to be a type-checking error.

[aspiwack]

The panic happens in the Data.Functor.Linear.Internal.Applicative module. On standalone instances derived via Generically. Not all of them:

This one breaks (the error appears to happen on the last line) ❌

deriving via
  Generically1 (Product f g)
  instance
    (Applicative f, Applicative g) => Applicative (Product f g)

This one works ✔️

deriving via
  Generically1 ((,) a)
  instance
    Monoid a => Applicative ((,) a)

Why there is a different between the two does elude me some. And why only in ghci? This is a weird puzzle.

[treeowl]

Could it be a bug in GHC's implementation of Template Haskell? Have you reported a GHC bug?

[aspiwack]

I haven't reported a GHC bug yet (there doesn't seem to be any Template Haskell involved anyway). As I don't know what to report 🙂 .

I'll try to minimize later this week, now I've got to go. I've had a look at GHC's source to see where could the source of this message be, and it's not obvious.

[aspiwack]

@monoidal points me at the fact that @andreasabel has already mentioned this very bug in the GHC bug tracker https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7105#note_421618 .

[andreasabel]

Maybe you want to fix the typo testExecptionOnMem to testExceptionOnMemwhile you are at it.

[aspiwack]

You know, it was all search and replace 🙂 .

Thanks for noticing!

[aspiwack]

This PR has now been changed to only care about GHC 9.2. The tasty-hedgehog bits are now handled by #415 .

[aspiwack]

Rebased. I still don't want to merge though. Let me (or someone) figure out what is happening with ghci.

[aspiwack]

Here is a minimised version of the bug (on GHC 9.2.2).

Uncomment any of the two commented signatures and the module seems to compile (I have yet to figure out why… it should fail to derive the instance I'm a little puzzled). At any rate, it makes the anomaly disappear.

{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE NoImplicitPrelude #-}

module Data.Functor.Linear.Internal.Applicative
  ( Applicative (..),
  )
where

import GHC.Types

-- type Product :: (Type -> Type) -> (Type -> Type) -> Type -> Type
data Product f g a = Pair (f a) (g a)

-- type Generically1 :: (Type -> Type) -> Type -> Type
newtype Generically1 f a = Generically1 (f a)

type Functor :: (Type -> Type) -> Constraint
class Functor f where
class Functor f => Applicative f where

deriving instance (Functor f, Functor g) => Functor (Product f g)

deriving via
  Generically1 (Product f g)
  instance
    (Applicative f, Applicative g) => Applicative (Product f g)

[aspiwack]

The bug appears to be fixed on (a recent) master:

$ ghci src/Data/Functor/Linear/Internal/Applicative.hs 
GHCi, version 9.3.20220406: https://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Data.Functor.Linear.Internal.Applicative ( src/Data/Functor/Linear/Internal/Applicative.hs, interpreted )

src/Data/Functor/Linear/Internal/Applicative.hs:29:18: error:
    • Couldn't match kind ‘k’ with ‘*’
      Expected kind ‘* -> *’, but ‘f’ has kind ‘k -> *’
      ‘k’ is a rigid type variable bound by
        the deriving clause for ‘Generically1 (Product f g)’
        at src/Data/Functor/Linear/Internal/Applicative.hs:27:3-28
    • In the first argument of ‘Applicative’, namely ‘f’
      In the stand-alone deriving instance for
        ‘(Applicative f, Applicative g) => Applicative (Product f g)’
   |
29 |     (Applicative f, Applicative g) => Applicative (Product f g)
   |                  ^

Maybe we can use this error message to build a workaround.

[aspiwack]

Indeed, just adding some type signature in the via bit of the standalone deriving ensures that the type of f doesn't have rigid variables or whatnot. It's probably still a bug, actually. I wonder if there is something to report here.

[aspiwack]

I am a little bit confused as to why, locally, stack tells me that GeneralizedNewtypeDeriving is available, and on the CI it fails. But not with Cabal. No matter, I have an easy fix.

[aspiwack]

I wrote an issue upstream ghc!21514. I'll give myself a little time to think of a better workaround. Then we will be able to merge.

[aspiwack]

I haven't found a better workaround. So we'll go with this, even though it's rather inelegant and fragile (it's probably a good idea to use GHC2021 as the default language in Cabal to avoid the fragility, but I think I had good reasons not to do that at some point, so I won't do this immediately).