Support GHC 9.14.1.

[jonathanknowles]

Adds support for GHC 9.14.1:

• Bumps the upper bound on base to < 4.23;
• Bumps the list of GHC versions in tested-with;
• Regenerates CI using the latest version of haskell-ci.

Related issues:

• Support ghc-9.14 #197
• Metadata revision request: parsec-3.1.18.0: bump base upper bound for GHC 9.14.1 compatibility. haskell-infra/hackage-trustees#431

[jonathanknowles]

I've tested CI on a fork here: https://github.com/jonathanknowles/parsec/actions/runs/26814866678.

[andreasabel]

@wz1000 : In the light of https://gitlab.haskell.org/ghc/packages/parsec/-/commit/15f8a71056a4e056881333d8b7ec32b6af6e92d9 do you wish to handle this?
If this is merge here as-is it might depart from the state you have in the GHC submodule...

[wz1000]

There is no issue on the GHC side if this is merged as is.

[andreasabel]

@wz1000 : does the GHC team want to take over parsec?
I think in the past it was in control through @hvr, and then through @phadej (I suppose), but both have become unresponsive.

[jonathanknowles]

@andreasabel Many thanks for your help with this.

Do you know who might be able to help with the related Hackage metadata revision request?

• Metadata revision request: parsec-3.1.18.0: bump base upper bound for GHC 9.14.1 compatibility. haskell-infra/hackage-trustees#431

[phadej]

and then through @phadej (I suppose), but both have become unresponsive.

Not true at all. Can't people have holidays. You should apologize.

[jonathanknowles]

Hi @phadej, many thanks for picking this up and moving it forward.

I noticed that this PR was closed without explanation, and that a virtually identical PR was opened shortly afterwards:

• Test against GHC-9.14 #200

AFAICT the only difference between the two PRs is the addition of an x-revision: 1 field to the cabal file. The CI changes and version constraint changes are otherwise identical.

I completely respect that you are under no obligation to accept PRs, or to give explanations!

But would you be willing to share your reasons for closing this PR rather than requesting a small amendment, which I would have been happy to make? I'm keen to avoid wasting effort in future, and I'd greatly appreciate any guidance you can offer.

I also wanted to note that this has been a long-running issue:

• On 2025-06-12 (almost exactly one year ago):
  • @bgamari opened the following PR to add GHC 9.14 support:
    • Bump base upper bound to <4.23 #193
• On 2026-01-11 (five months ago):
  • @erikd opened the following issue:
    • Support ghc-9.14 #197

Neither of the above saw any response from a maintainer until now.

Given that this has been unresolved for nearly a year, and that this is a core (boot) package with 960 direct and 15072 indirect reverse dependencies on Hackage, I hope this helps explain why others have felt the need to step in and try to move things forward!

Best regards
Jonathan

[phadej]

PR rather than requesting a small amendment

It's quicker to do the small amendment myself, also testing locally that it's ok by making a dry-run revision upload. In other libraries I maintain I simply ask to open an issue (e.g. https://github.com/haskellari/assoc/blob/master/CONTRIBUTING.md). Going back & forth asking for small changes is waste of everyone's time. I'll add CONTRIBUTING.md to this repository.

No-one pinged me on #193, so it just felt through the cracks.