Facundo Domínguez
Facundo Domínguez
> where I'd push all the GHC 9.8 compatibility changes (without CPP-guarding them) as a new baseline for this branch going forward? That works. There are two strategies to maintain...
> Does this make sense? Yes, I think #2380 works. Removing the CPP guards also sounds good to me. I expect the encapsulation to be harder for dealing with annotations,...
:+1: there is a branch `develop-ghc-9.8` now.
#2430 is removing the explicit dependency on `ghc-internals`. Perhaps that makes support for GHC 9.8 easier.
Should we close this task as completed?
hm, probably we should document the existence of `develop-ghc-9.8` somewhere.
As far as I understand, [loadDependencies](https://github.com/ucsd-progsys/liquidhaskell/blob/6c2e11d0fa301250f7a43e59d7850ce37a3dc078/liquidhaskell-boot/src/Language/Haskell/Liquid/GHC/Plugin.hs#L490) is getting the annotations from dependencies.
Hello @gergoerdi, should I close this PR, or would you like to get CI passing?
> LH doesn't really need to know much about them This would be my expectation, but I haven't worked with this part of the code base yet.
Inlining a function that uses type classes could be problematic. This might be related to the bit-rotted support for type classes (#2450).