Stackage haddock core libs source links broken

[hsyl20]

Some source links on stackage haddock pages are wrong.

To reproduce:

• go to https://www.stackage.org/haddock/lts-24.4/base-4.20.1.0/Data-List-NonEmpty.html
• click on the source link for the NonEmpty datatype
• it redirects to https://www.stackage.org/haddock/lts-24.4/ghc-internal-9.1002.0-77c7/src/GHC.Internal.Base.html#NonEmpty
• while the correct link is https://www.stackage.org/haddock/lts-24.4/ghc-internal-9.1002.0/src/GHC.Internal.Base.html#NonEmpty (i.e. the package identifier shouldn't contain what is presumably a unit-id hash -77c7).

It was working before ghc-internal was introduced (e.g. see on https://www.stackage.org/haddock/lts-23.27/base-4.19.2.0/Data-List-NonEmpty.html)

[juhp]

Thanks for reporting this.

I think you are saying it was working before ghc-9.10 ;o) Sigh
Stackage uses the default upstream tarballs via stack to build.

I think this is actually a GHC issue (I do wish the ecosystem would stop changing paths).
Not sure how Hackage handles it - perhaps it massages the paths somehow?

[juhp]

Same problem also in nightly: https://www.stackage.org/haddock/nightly-2025-08-15/base-4.21.0.0/Data-List-NonEmpty.html

[juhp]

Actually I might be wrong above - maybe this issue is specific to Stackage perhaps.
(I also checked hoogle, hackage and Fedora doc packages (funny I thought there was a similar problem there, but it was okay for this at least for core libs.)

I guess the next thing to check would be the upstream bin dists.

[juhp]

I guess the next thing to check would be the upstream bin dists.

So I tried via stack --resolver lts setup and indeed the docs use the hashes:

~/.stack/programs/x86_64-linux/ghc-tinfo6-9.10.2/share/doc/ghc-9.10.2/html/libraries/base-4.20.1.0-8f3d/Data-List-NonEmpty.html =>
~/.stack/programs/x86_64-linux/ghc-tinfo6-9.10.2/share/doc/ghc-9.10.2/html/libraries/ghc-internal-9.1002.0-77c7/src/GHC.Internal.Base.html#NonEmpty

like you are seeing. I suspect then maybe we are massaging the directories we install?

@chreekat does that ring any bells?

I will try to check what is happening, but I am less familiar with how we publish our haddocks.

[chreekat]

Is the problem Stack?

• @hsyl20 points out that Stackage is using the unit-id (or something) incorrectly
• @juhp replicates the behavior with stack

Paging @mpilgrem

[mpilgrem]

I am not sure I follow the question. For, say, GHC 9.10.3, it provides HTML Haddock documentation for GHC boot packages in folders like:

• ...\ghc-9.10.3\doc\html\libraries\base-4.20.2.0-39f9

That is not Stack's doing.

EDIT: But GHC 9.8.4 does the same:

• ...\ghc-9.8.4\doc\html\libraries\base-4.19.2.0-943b

So, what has changed? I am not conscious of any Stack change. Under the hood, Stack is - I think - using Cabal's Setup.hs haddock. Is Cabal-3.12.1.0 doing something different to Cabal-3.10.3.0?

EDIT2: After a little investigation, stack haddock moves HTML files into folders in .stack-work\install\ ... \doc named after package name-version (not package id/key) and that seems to be problematic for GHC 9.8.4 (after patching the duff Haddock references in its *.conf files, on Windows) and GHC 9.10.3. Maybe it was never revealed because most of the documentation in the base package did not link to other packages.

e.g The link to source here also does not work:

• https://www.stackage.org/haddock/lts-23.8/base-4.19.2.0/GHC-Exts.html#v:seq

EDIT3: Working back in time, GHC 9.6.7 provides HTML Haddock documentation for GHC boot packages in folders like:

• ...\ghc-9.6.7\doc\html\libraries\base-4.18.3.0

So, it looks like there was a breaking change after GHC 9.6.7.

[chreekat]

Aha. I re-read this thread and looked into things a bit more, and I think I misread Jens' statement. But we may be arriving at a similar conclusion.

After a little investigation, stack haddock moves HTML files into folders in .stack-work\install\ ... \doc named after package name-version (not package id/key) and that seems to be problematic for GHC 9.8.4 (after patching the duff Haddock references in its *.conf files, on Windows) and GHC 9.10.3. Maybe it was never revealed because most of the documentation in the base package did not link to other packages.

There are some links to other files, like ghc-prim, that have existed in base for a while. Maybe we can find an example to verify that this has become a problem since some time after 9.6.7.

[chreekat]

Yep,

Problem: https://www.stackage.org/haddock/lts-23.28/base-4.19.2.0/Data-Type-Ord.html (GHC 9.8.4)
Link: the 'Source' link for method (==) in instance Eq (OrderingI a b).

The same link is fine on https://www.stackage.org/haddock/lts-22.44/base-4.18.3.0/Data-Type-Ord.html (GHC 9.6.7)

[mpilgrem]

I am going to open a corresponding issue at Stack's repository.