Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GHC 9.2 support #1482

Closed
wants to merge 5 commits into from
Closed

Add GHC 9.2 support #1482

wants to merge 5 commits into from

Conversation

brandon-leapyear
Copy link
Contributor

@brandon-leapyear brandon-leapyear commented Nov 15, 2021

This is an old work account. Please reference @brandonchinn178 for all future communication


Related: #1475

Copy link
Contributor

@akhesaCaro akhesaCaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution,

Here some additional tasks that mustn't be forgotten :

Are you okay with doing that?

Note : The PR (#1475) must be merged and this PR rebased before integrating it to the code base.

@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Nov 28, 2021

This is an old work account. Please reference @brandonchinn178 for all future communication


I rebased and updated nix/README + github actions. I don't use Nix, so I won't be able to help with the Nix point, and I don't know what you mean by "Cookbook"

type MkLink (arr :> sub) _ = TypeError (PartialApplication HasLink arr)
type MkLink (arr :> sub) _ = TypeError (PartialApplication (HasLink :: * -> Constraint) arr)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was added 2 weeks ago: 42b7d0e

GHC 9.2 is stricter about this:

GHC is stricter about checking for out-of-scope type variables on the right-hand sides of associated type family instances that are not bound on the left-hand side.

source

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aab7e0d added another instance of this problem:

type ServerT (arr :> sub) _ = TypeError (PartialApplication HasServer arr)

HasServer needs to become (HasServer :: * -> [*] -> Constraint) (and Constraint needs to be added to the import list).

@ysangkok
Copy link
Contributor

@brandon-leapyear Looks like the 9.2 build is failing because of an old cabal-install version.

@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Jan 20, 2022

This is an old work account. Please reference @brandonchinn178 for all future communication


@ysangkok I changed GHC 9.2 to run with Cabal 3.6, but I'm still getting errors. I don't use Cabal myself, can you help fix that?

@akhesaCaro
Copy link
Contributor

Okay I will try on my side and keep you posted.

@gdeest
Copy link
Contributor

gdeest commented Jan 24, 2022

I am not entirely making sense of the Cabal failure ; it seems to me that Cabal commits to a bound-to-fail plan because the constraints it tries to satisfy do not match pre-installed versions, but I am not entirely sure.

I am slightly concerned with the amount of allow-newer stanzas we have in the cabal.project files, especially for 9.2:

-- https://github.com/chordify/haskell-servant-pagination/pull/12
allow-newer: servant-pagination-2.2.2:servant
allow-newer: servant-pagination-2.2.2:servant-server

allow-newer: servant-js:servant

-- ghc 9
allow-newer: tdigest:base

-- ghc 9.2
allow-newer: basement:base
allow-newer: binary:bytestring
allow-newer: generics-sop:base
allow-newer: generics-sop:ghc-prim
allow-newer: generics-sop:template-haskell
allow-newer: http-media:base
allow-newer: lucid:base
allow-newer: memory:base
allow-newer: openssl-streams:bytestring
allow-newer: servant-js:base
allow-newer: servant-js:base-compat
allow-newer: servant-js:lens
allow-newer: servant-multipart:bytestring
allow-newer: servant-swagger:base-compat
allow-newer: singleton-bool:base
allow-newer: sop-core:base
allow-newer: swagger:base
allow-newer: swagger2:base
allow-newer: swagger2:base-compat-batteries
allow-newer: swagger2:bytestring
allow-newer: swagger2:lens
allow-newer: swagger2:template-haskell
allow-newer: swagger2:time

I am guessing we don't really have a choice because these libraries do not have 9.2-compatible releases yet ?

@gdeest
Copy link
Contributor

gdeest commented Jan 25, 2022

I have managed to get past Cabal configure, but basement fails to build with GHC 9.2. We'll have to exclude some things from the 9.2 build.

@tchoutri
Copy link
Contributor

Yes, the Hackage & Stackage folks have had some issues with basement and foundation, looks like the 9.2 support for these libraries will come one day™

@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Feb 1, 2022

This is an old work account. Please reference @brandonchinn178 for all future communication


@gdeest in the future, can you let me know before you push changes to my fork? Thanks!

@@ -821,7 +823,7 @@ instance (HasContextEntry context (NamedContext name subContext), HasServer subA
-- Erroring instance for 'HasServer' when a combinator is not fully applied
instance TypeError (PartialApplication HasServer arr) => HasServer ((arr :: a -> b) :> sub) context
where
type ServerT (arr :> sub) _ = TypeError (PartialApplication HasServer arr)
type ServerT (arr :> sub) _ = TypeError (PartialApplication (HasServer :: Type -> Constraint) arr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't that be Type -> [Type] -> Constraint?

@ysangkok
Copy link
Contributor

ysangkok commented Feb 2, 2022

I think it is a bad idea to make the default stack.yaml on the master branch refer to unreleased versions of libraries (e.g. lens, foundation, etc). I see how it makes sense to do this for development purposes, though. But if this branch isn't supposed to be merged, maybe it would be clearer to mark it "Draft"? After dependencies are fixed or removed, it could be marked ready for review again.

stack.yaml Outdated Show resolved Hide resolved
stack.yaml Outdated Show resolved Hide resolved
@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Feb 2, 2022

This is an old work account. Please reference @brandonchinn178 for all future communication


I intended for the PR to be merged now. I wasn't sure how Stack is used in this project, e.g. if the standard build workflow is via Cabal, and the stack config is just there for reference. I've moved the Stack stuff into a new stack-ghc-9.2.yaml config.

I would prefer to not have a PR that I maintain open for an indefinite period of time. If you'd prefer to not merge any aspect of this PR at this time, feel free to close.

stack-ghc-9.2.yaml Outdated Show resolved Hide resolved
stack-ghc-9.2.yaml Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
@srid srid mentioned this pull request Feb 7, 2022
11 tasks
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
cabal.project Outdated Show resolved Hide resolved
@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Feb 24, 2022

This is an old work account. Please reference @brandonchinn178 for all future communication


@ysangkok can we get this merged anytime soon? I'd prefer to not be maintaining this long-term

@ysangkok
Copy link
Contributor

ysangkok commented Mar 9, 2022

@brandon-leapyear I am not a project maintainer, so it is not my decision to make. But I have submitted #1555 which achieves GHC 9.2 compatibility for a subset of packages that work on GHC 9.2, and marks the others as unbuildable. I prefer this approach due to how it doesn't legitimize unofficial forks of dependencies (as previously mentioned).

@brandon-leapyear
Copy link
Contributor Author

brandon-leapyear commented Mar 9, 2022 via email

@maksbotan
Copy link
Contributor

@ysangkok @brandon-leapyear please check if this PR is still relevant after merge of #1555.

And thanks for your work!

@brandon-leapyear brandon-leapyear deleted the chinn/ghc-9.2 branch March 21, 2022 23:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants