Closed RyanGlScott closed 1 month ago
Note that I can't reproduce this bug on the ghc-9.6
branch of this repo, so presumably https://github.com/haskell/haddock/pull/1597 helped (cc @FinleyMcIlwaine).
Regarding the buggy code though, this comment looks suspicious to me...
After some debugging,
choices = [Lens, Lens]
gres = [Lens parent:ReifiedLens defined at Bug.hs:4:20,
Lens defined at Bug.hs:6:1]
gresToAvailInfo gres = [Lens{Lens}, ReifiedLens{Lens}]
noChildren = [Lens, ReifiedLens]
So the problem seems to be that gresToAvailInfo
turns the data constructor Lens
into its parent type constructor ReifiedLens
and we lose the information that it came from a data constructor.
Hi, thank you for this ticket, but Haddock now lives full-time in the GHC repository! Read more at https://discourse.haskell.org/t/haddock-now-lives-in-the-ghc-repository/9576.
Let me know if you feel it is still needed, and I'll migrate it. :)
(Originally observed in https://github.com/ekmett/lens/pull/1042.)
Here is a stripped-down version of Haddocks that you'd find in a typical
lens
module:Note that the
'Lens'
reference inf
's Haddocks is ambiguous, as there is both a type and a data constructor namedLens
. My reading of this section of the Haddock readthedocs is that when such ambiguities arise, Haddock will default to the type name:This is not what I observe in practice, however. If you render the Haddocks for this module by running the following command:
You will end up with the following HTML page:
I believe there are two bugs here:
RenderedLens
", which is completely different from the original "'Lens'
". I'm not sure why this happens.RenderedLens
refers to the value-level version ofLens
, not the type-levelLens
. If I understood the readthedocs correctly, it should be the other way around.