Fix building against GHC 9 / Lens 5 #1694
Conversation
It looks like something in the GHC 9 / Lens 5 combination yields unexpected results when using view on Lens', with GHC complaining that it's passed a Lens' instead of a Getting (which should still be compatible). Commenting out the signatures of Ganeti.Network.poolLens, Ganeti.Network.poolArrayLens and Ganeti.Utils.MultiMap.multiMapL makes Ganeti build again, so I'd keep this ugly hack until we figure out what's actually wrong. Signed-off-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
There was a problem hiding this comment.
Dear @apoikos,
does this PR address compile errors like this one?
src/Ganeti/Utils/MultiMap.hs:103:17: error:
• Couldn't match type: forall (f :: * -> *).
Functor f =>
(S.Set v0 -> f (S.Set v0)) -> MultiMap k v0 -> f (MultiMap k v0)
with: (S.Set v -> Const (S.Set v) (S.Set v))
-> MultiMap k v -> Const (S.Set v) (MultiMap k v)
Expected: k -> Getting (S.Set v) (MultiMap k v) (S.Set v)
Actual: k -> Lens' (MultiMap k v0) (S.Set v0)
and what will happen if the type signature is removed? Will Haskell compute the "right one" implicitly? If so, what are the implications of automatic type signatures?
TIA, Sascha.
|
@saschalucas yes, it fixes these errors. In general, type signatures are optional as long as the compiler can figure them out. For most simple functions, the compiler can rely on type inference to guess the function's signature. If the compiler can infer a function's type and a signature has been explicitly defined, then these two must match, otherwise - as in this case - the compilation errors out. Now, it looks like with have an additional error with the tests, one that I didn't catch in Debian because I'm not running the Haskell tests there during build. I will address this shortly. |
There was a problem hiding this comment.
Thanks @apoikos for your explanation. Let's go ahead an use automatic type signatures if that helps to run on newer Haskell stacks.
As you mentioned, github CI hs-tests fails ATM. Fixing this would be nice, too.
Citing the GHC 9.0.1 changelog[1]:
Breaking change: Template Haskell splices now act as separation points
between constraint solving passes. It is no longer possible to use an
instance of a class before a splice and define that instance after a
splice. For example, this code now reports a missing instance for C
Bool:
```
class C a where foo :: a
bar :: Bool
bar = foo
$(return [])
instance C Bool where foo = True
```
In other words, code order matters in Template Haskell files, which
breaks the Haskell test build with GHC >= 9.0.1. Fix this by reordering
various Arbitrary instances so that they are defined before being used.
Also the Arbitrary instance for IAllocatorParams was silently acting as
a generic instance for (Container JSValue), providing instances for
DiskParams, HypervisorState and DiskState as well. Change the Arbitrary
instance declaration to Arbitrary (Container JSValue) to better reflect
its generic purpose.
[1] https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/9.0.1-notes.html#highlights
Signed-off-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
|
@saschalucas, I fixed the other build issues as well. |
|
is this commit planned to be backported into Debian bookworm somehow? worried about upgrading our clusters to bookworm right now... |
It looks like something in the GHC 9 / Lens 5 combination yields unexpected results when using view on Lens', with GHC complaining that it's passed a Lens' instead of a Getting (which should still be compatible). Commenting out the signatures of Ganeti.Network.poolLens, Ganeti.Network.poolArrayLens and Ganeti.Utils.MultiMap.multiMapL makes Ganeti build again, so I'd keep this ugly hack until we figure out what's actually wrong.