Missing links to GHC.OldList when re-exporting Foldable

[sjakobi]

With

module Lib (Foldable(..)) where

I get

Warning: Lib: could not find link destinations for:
    foldl foldl1 foldr foldr1 Array

where previously the only warning was for Array.

[sjakobi]

(I was also confused about fold, foldr', foldl' and toList missing from the Foldable methods but that's just because Prelude doesn't re-export them.)

[alexbiehl]

Is this a bug in renamer? It needs to consider the modules where fold, foldr', ... originate.

[sjakobi]

The chain of re-exports involved here is quite impressive:

• GHC.OldList re-exports the entire module Data.OldList
• Data.OldList re-exports functions from GHC.List
• GHC.List defines foldl, foldl1 and foldr1, and re-exports foldrfrom GHC.Base

[sjakobi]

Unsurprisingly the iface docs section for the sample module is quite empty:

docs:
  Just identifier env:
       module header:
         Nothing
       declaration docs:
       arg docs:
       documentation structure:
         avails:
           [Foldable{Foldable, elem, foldMap, foldl, foldl1, foldr, foldr1,
                     length, maximum, minimum, null, product, sum;}]
       named chunks:
       haddock options:
       language:
         Just Haskell2010
       language extensions:
       declaration locations:
       splice locations:

What I don't understand is why the links LinkEnv we construct in processModules contains all kinds of stuff including functions from GHC.Integer.GMP.Internals but not the list folds.

[sjakobi]

What I don't understand is why the links LinkEnv we construct in processModules contains all kinds of stuff including functions from GHC.Integer.GMP.Internals but not the list folds.

Maybe that's related to GHC.Base and GHC.List having {-# OPTIONS_HADDOCK hide #-}?

[sjakobi]

Replacing the hide option in GHC.Base and GHC.List with not-home alleviates the problem:

We now get the missing links, but they direct to GHC.List instead of GHC.OldList. Since GHC.OldList recommends using GHC.List instead, that's not too bad.

There still appears to be an underlying problem with the way we construct the LinkEnv though.

[sjakobi]

For posterity, the attached file shows how the processModules.extLinks for a package depending only on base are composed with the current ghc- and haddock-head: link-env.txt

[sjakobi]

For posterity, the attached file shows how the processModules.extLinks for a package depending only on base are composed with the current ghc- and haddock-head: link-env.txt

Interestingly we do find GHC.Base.foldr linking to GHC.OldList there.

I should check whether the LinkEnv I get with my version of haddock is the same.

[alexbiehl]

`--dump-interface` to the rescue! Simon Jakobi <notifications@github.com> schrieb am Mo., 23. Juli 2018 um 22:47 Uhr:

…

For posterity, the attached file shows how the processModules.extLinks for a package depending only on base are composed with the current ghc- and haddock-head: link-env.txt Interestingly we do find GHC.Base.foldr linking to GHC.OldList there. I should check whether the LinkEnv I get with my version of haddock is the same. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AByiieen9PCs7CIfyP0gLsB7aKzQhO3_ks5uJjZzgaJpZM4VTG5x> .