Add support for ghc 9.0.1

[anka-213]

This integrates the changes from #281 and also fixes some Template Haskell issues caused by ghc-9.0.1 having stricter staging rules than earlier versions.

(Step towards haskell/haskell-language-server#297)

[jneira]

thanks again, maybe some of libs in the allow-newer list has been updated and could be removed

[anka-213]

@jneira Probably. Is there a way to automate that? My attempts requires me to loop between running cabal build and adding the single package it mentions to the list.
Can I tell cabal to display all packages that requires allow-newer?

[anka-213]

I've added references to mokus0/th-extras#8 and obsidiansystems/dependent-sum#57 in the cabal.project, so this can be built even before they are merged. They should be removed once those pull requests are merged.

[anka-213]

I'm not sure why it failed on CI. It worked for me locally. :/

[jneira]

That is my manual process too, I don't know an automate way to do it 😟

[anka-213]

@jneira If you have time, can you check if this patch works for you on ghc-9.0.1 or if it accidentally works for me locally because of some impurity?

[jneira]

@anka-213 I cant reproduce the error after a cabal update (sadly i didnt try before)
I've observed github ci has no cabal update so maybe the haskell action left it in a old index state, i would try to add a cabal update before start the build.

[anka-213]

@jneira Yep, that was the problem. Thanks!

[jneira]

@anka-213 hi! i think we could merge this one and remove one of the remote repo packages.
could you rebase master?, i hope it will not take much time.

[jneira]

@anka-213 i tried to fix the build with e96383a

[anka-213]

Those were introduced in this commit: ef59c28#diff-b8ed06757045fac949c89f2139a862498ad2b6d1f82c61a31e7c91d6cf0eaa70

Is that problem resolved now?

I guess it is, since CI succeeds.

[jneira]

he I suggested the change to fix the build there but this pr seems to fix it in another way, to investigate

[anka-213]

Oh, the answer is really simple. My changes includes upstream patches of those packages, so we no longer need to constrain the version.

[jneira]

the question is we can't do a hackage release until all upstream packages are there so not sure if we should merge this
the changes are not too pervasive so maybe there won't be much conflicts (and there is no too much prs to merge in master), thoughts?

[anka-213]

Oh, right. That's a good point. I didn't think of that. Otoh, it does still build successfully (I believe, haven't actually tried) on any ghc < 9 without those upstream patches, so it shouldn't really be a problem to put it on hackage.

[pepeiborra]

Are you sure that a Hackage release cannot be done? Technically, the package overrides in cabal.project are not impeding a Hackage release, as long as the package builds with a vanilla cabal.project in 8.10.

[jneira]

@pepeiborra mmm you are right, it will not work for 9.0.1, failing in the solver phase like the actual one (i've checked it, just in case it would be a build error and no solver error)

[jneira]

lgtm @anka-213 many thanks for working on this
will merge soon if nobody disagree