Support for GHC 9.0, 9.2 and 9.4 #406
Conversation
Since GHC 9.2, template haskell works like a barrier for the visibility of instances. Hence the instance declared after a template haskell chunk are not visible to code appearing before. I moved everything to the top of the file which fixed the compilation.
See release notes in https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.8.1.0.md related to the new `ppOrdering` field.
A new version of GHC was triggering a symbol conflict. Instead of importing the complete module, I just import the needed symbol.
GHC 9.4 requires that selector name are totally unambiguous. This was not the case for selectors `A.name` and `A.type'`. I wrote an unambigous pattern match instead.
Fix the problems introduced by https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst Roughly, `g` is not always equal to `(\x -> g x)`. In GHC 9.2.4 and GHC 9.4, this was reverted and a new extension `DeepSubsumption` was introduced to change the behavior, with the old behavior by default. However it is unclear if this will be backported to GHC 9.0.3 and at least, using the new syntax fix the build for 9.0.X and 9.2.X < 9.2.4.
llvm-hs/Setup.hs
Outdated
| #endif | ||
| PreProcessor { | ||
| #if MIN_VERSION_Cabal(3,8,0) | ||
| ppOrdering = \_ _ ms -> pure ms, |
There was a problem hiding this comment.
Hello! Maybe unsorted would be better than manual implementation?
There was a problem hiding this comment.
Yes, you are right. I added a code suggestion.
|
|
||
| instance Monad m => ScopeAnyCont (AnyContT m) where | ||
| scopeAnyCont = lift . flip AnyCont.runAnyContT return | ||
| scopeAnyCont a = lift (((\cont -> AnyCont.runAnyContT cont return)) a) |
There was a problem hiding this comment.
Am I reading this incorrectly, or are there unnecessary parens here, around the \cont -> ... return part? I think the rhs expr is equivalent to lift $ AnyCont.runAnyContT a return,
There was a problem hiding this comment.
I've done theses changes with search and replace, so yeah, that's totally possible.
|
|
||
| import LLVM.Internal.FFI.LLVMCTypes (mdSubclassIdP) | ||
|
|
||
| genCodingInstance [t|A.DebugNameTableKind|] ''FFI.DebugNameTableKind |
There was a problem hiding this comment.
Why did you have to move those?
There was a problem hiding this comment.
Sorry, I thought I explained that in details in the commits details.
Since GHC 9.2, template haskell code works as a "barrier" for visibility of instances. So an instances defined AFTER a TH piece of code cannot be seen before.
As an example, consider the following:
data Foo = Foo
-- This functions uses the Eq instance for Foo
-- Which is define after someTH, so not visible here.
cmpFoo :: Foo -> Foo -> Bolo
cmpFoo a b = a == b
$(someTH)
deriving instance Eq Foo|
Hello @apaszke! Are there some merge blockers? If it's ready I can port it for LLVM 12/14/15 respectively. |
Hello,
This bunch of commits fix support for GHC 9.0 to GHC 9.4.
I've tested the build with the three versions, and also
cabal test all.See individual commits for details of each changes.
Note: I've based my work on top of the
llvm-9branch, because that's what we are using at work. It is unclear if I must rebase on top of the other branch, or if the other branchs are pulling this branch. Please tell me if I need to do something else.