unbreak cabal haddock --disable-documentation

[ulysses4ever]

Trying to fix my fault from #8259 (thanks @andreasabel for noticing): cabal haddock --disable-documentation seems to work as expected with this patch.

Below is a description of a problem I initially had but no more. Preserved for historical interest.

---

But the testsuite is not cooperating. I see two options: you, guys, help me or allow me to ditch the test.

Here's the deal with the test:

main = cabalTest . withRepo "repo" . fails $
    cabal "haddock" ["--disable-documentation", "B"]

should work, but it fails even when

❯ cabal run cabal-tests -- --with-cabal=(cabal list-bin cabal) cabal-testsuite/PackageTests/NewHaddock/DisableDoc/cabal.test.hs --accept

I see the output I'm expecting to see, in particular:

 100% (  2 /  2) in 'B'
Warning: B: could not find link destinations for:

        - A.a

but the output ends with

cabal-tests: callProcess: /nix/store/glag1h91br1sqk489rzzp6mvmxf0pmiy-ghc-9.0.2/bin/runghc-9.0.2 "--" "--ghc-arg=-i" "--ghc-arg=-no-user-package-db" "--ghc-arg=-package-db" "--ghc-arg=/home/artem/.cabal/store/ghc-9.0.2/package.db" "--ghc-arg=-package-db" "--ghc-arg=/home/artem/tmp/cabal/enable-doc-regress/cabal/dist-newstyle/packagedb/ghc-9.0.2" "--ghc-arg=-package-id" "--ghc-arg=Cabal-3.9.0.0-inplace" "--ghc-arg=-package-id" "--ghc-arg=Cabal-syntax-3.9.0.0-inplace" "--ghc-arg=-package-id" "--ghc-arg=async-2.2.4-2b04cd6dcc0fc474e0072aec3462b9c67410113d7befe87d8f668b6a29dfe996" "--ghc-arg=-package-id" "--ghc-arg=base-4.15.1.0" "--ghc-arg=-package-id" "--ghc-arg=cabal-testsuite-3-inplace" "--ghc-arg=-package-id" "--ghc-arg=clock-0.8.3-12cb68ccaf6e6206378be8082c1ee7435ae9bbce4022f1012bd6cd3e5c8fc2aa" "--ghc-arg=-package-id" "--ghc-arg=exceptions-0.10.4" "--ghc-arg=-package-id" "--ghc-arg=filepath-1.4.2.1" "--ghc-arg=-package-id" "--ghc-arg=optparse-applicative-0.16.1.0-72520bdb9dc24ef310719d7357cf6ce0dac24c8b958b2d2663b3d141a87f2fd6" "--ghc-arg=-package-id" "--ghc-arg=process-1.6.14.0-42e0058a6e7535eea211d226cecb5365b21bf90abcca43d0f0527ff0319ccdca" "--ghc-arg=-package-id" "--ghc-arg=transformers-0.5.6.2" "cabal-testsuite/PackageTests/NewHaddock/DisableDoc/cabal.test.hs" "--builddir" "/home/artem/tmp/cabal/enable-doc-regress/cabal/dist-newstyle/build/x86_64-linux/ghc-9.0.2/cabal-testsuite-3" "cabal-testsuite/PackageTests/NewHaddock/DisableDoc/cabal.test.hs" "--with-cabal" "/home/artem/tmp/cabal/enable-doc-regress/cabal/dist-newstyle/build/x86_64-linux/ghc-9.0.2/cabal-install-3.9.0.0/x/cabal/build/cabal/cabal" "--accept" (exit 1): failed

Which is no good, as far as I understand. If I remove fails in the .hs file, the failure in the end seems to be the same. So, I'm probably using fails wrong?..

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[ulysses4ever]

More or less, what I see locally reproduces in the CI: https://github.com/haskell/cabal/runs/7571243588?check_suite_focus=true

[Mikolaj]

Is Warning: B: could not find link destinations for a hard error that exits with 1, or is it just a warning after which you continue?

[ulysses4ever]

@Mikolaj wow, I was positive that removing fails didn't change the output and was still saying "fail" but now it's not. SO, removing fails works and if I --accept output and remove the patch, then the test fails, so it's good. Waiting for CI.

[Mikolaj]

Could we perhaps extend the test to also display the warning (for some other module?)? The very text of the warning may be fragile, but if we notice we need to update it too often as haddock gets message overhauls, we can grep for a couple of keywords instead.

[ulysses4ever]

Good point. See the assert below. Is it good?

[ulysses4ever]

Oh, I see you approved, so I guess it's good.

[ulysses4ever]

@Mikolaj does it need a changelog entry?

[Mikolaj]

@Mikolaj does it need a changelog entry?

I don't think so. You are fixing a change that wasn't yet released, so nobody's going to know. :)

[ulysses4ever]

Right, I forgot #8259 wasn't backported to 3.8.

[andreasabel]

Thanks @ulysses4ever !