Compatibility with optparse-applicative-0.18

[andreasabel]

optparse-applicative-0.18 switched to prettyprinter, so some reexports are missing now.

• v0.18: text no longer exported from Options.Applicative.Help.Pretty pcapriotti/optparse-applicative#481

Building library for xrefcheck-0.2.2..
[17 of 19] Compiling Xrefcheck.CLI    ( src/Xrefcheck/CLI.hs, /Users/abel/bin/src/xrefcheck/dist-newstyle/build/x86_64-osx/ghc-9.2.8/xrefcheck-0.2.2/build/Xrefcheck/CLI.o, /Users/abel/bin/src/xrefcheck/dist-newstyle/build/x86_64-osx/ghc-9.2.8/xrefcheck-0.2.2/build/Xrefcheck/CLI.dyn_o )

src/Xrefcheck/CLI.hs:34:46: error:
    Module ‘Options.Applicative.Help.Pretty’ does not export ‘displayS’
   |
34 | import Options.Applicative.Help.Pretty (Doc, displayS, fill, fillSep, indent, renderPretty, text)
   |                                              ^^^^^^^^

src/Xrefcheck/CLI.hs:34:79: error:
    Module
    ‘Options.Applicative.Help.Pretty’
    does not export
    ‘renderPretty’
   |
34 | import Options.Applicative.Help.Pretty (Doc, displayS, fill, fillSep, indent, renderPretty, text)
   |                                                                               ^^^^^^^^^^^^

src/Xrefcheck/CLI.hs:34:93: error:
    Module ‘Options.Applicative.Help.Pretty’ does not export ‘text’
   |
34 | import Options.Applicative.Help.Pretty (Doc, displayS, fill, fillSep, indent, renderPretty, text)
   |                                                                                             ^^^^
Error: cabal: Failed to build xrefcheck-0.2.2

This PR restores compatibility with the latest optparse-applicative.

I simplified the code to display the help text, but the rendering still looks fine:

To ignore a link in your markdown, include "<!-- xrefcheck: ignore <mode> -->"
comment with one of these modes:
  "link"                   Ignore the link right after the comment.
  "paragraph"              Ignore the whole paragraph after the comment.
  "file"                   This mode can only be used at the top of markdown or
                           right after comments at the top.

So maybe the code was unnecessary complicated to begin with.

On hackage I added upper bound optparse-applicative < 0.18, e.g. https://hackage.haskell.org/package/xrefcheck-0.2.2/revisions/.

[andreasabel]

What's up with your CI?

[gromakovsky]

@andreasabel thank you for this PR. We are currently switching from Buildkite to GitHub Actions in #267. I hope we'll finish soon and then CI might start working in this PR after rebasing on the latest master branch.

[andreasabel]

Thanks for the heads up, @gromakovsky ! I leave further handling of this PR to you, please use/modify it in any way you want.

[aeqz]

In this case, readMaybe comes from Text.Read and takes a String parameter, so it does not compile for me unless this type parameter application is removed.

[andreasabel]

I was surprised that I had to add it, because it is orthogonal to the concern of this PR, namely optparse-applicative.
Let me investigate some more...

[andreasabel]

So indeed stack build fails now (which uses LTS 19 which is GHC 9.0), but cabal build -w ghc-9.2.8 succeeds and needs this change.
I am gonna remove this patch, it is something to be sorted out when migrating from GHC 9.0 to 9.2 and up.
(Note that GHC 9.2.8 is the currently recommended version of GHC.)

[aeqz]

Yes, it should be updated at some point. I will create an issue referencing this comments thread. Thank you!

[andreasabel]

NB: cabal build -w ghc-9.0.2 fails because of:

• connection-0.2.5 fails to build with GHC 9.0.2 vincenthz/hs-connection#54

[aeqz]

I have tried this code changes on my device while CI is fixed.

After making it build (mentioned in other comment), tests are passing, but part of the CLI help message has to be fixed:

master:

This PR:

Maybe we can also add a golden test for this help message.

[andreasabel]

After making it build (mentioned in other comment), tests are passing, but part of the CLI help message has to be fixed:

I can reproduce it with the stack build, but it does not happen when built with GHC 9.2.8 on cabal.

However, the stack build uses optparse-applicative-0.16 rendering this whole enterprise obsolete (compatibility with 0.18).
I suppose this PR comes too early, should be reconsidered when the build basis has moved on to stack nightly or an LTS that packages 0.18.

[aeqz]

but it does not happen when built with GHC 9.2.8 on cabal

So all the points that I mentioned seem to be related to the GHC version difference. We will go back to this PR when upgrading the stack setup, probably after finishing the ongoing CI work!

[int-index]

Not knowing about this PR, I ended up with a similar fix in 74ed941.

So I think all relevant changes are now in master. Feel free to reopen if I missed something.