6

moduleには、 moduleのメンバーにBリンクする link を含むドキュメントがあります。モジュールでは、モジュールをインポートします。Haddock は、これを へのリンクとしてレンダリングします。つまり、 にある関数ではなく、タイプ(存在しない) を指します。'A.foo'fooAABA.html#t:foo foofooA.html#v:foo

  • t:Haddockが小文字で始まる変数にリンクするのはなぜですか? それはバグですか？'A.Foo'型またはコンストラクターである可能性があるため、名前空間の問題があります。foo変数は、少なくとももっともらしいと思われるからです。
  • リンクを偽造する方法はありますか? これをコードサンプルで書いているので、 としてレンダリングする必要がありますfoo。アンカーを試しましたが、それらはモジュール名としてレンダリングされ、直接ハイパーリンクの場合、表示されるテキストを制御できません。
  • 私はポスト プロセッサを検討しました ( に置き換えますt:[a-z])v:が、これにはカスタムの Setup.hs が必要であり、問​​題が発生し、非常に見苦しくなります。
  • foo変数であると指定するなど、より合理的な動作を得るための Haddock コマンド ライン フラグが見つかりませんでした。
  • 循環インポートを導入せずにAtoのインポートを追加することはできません。これは、純粋にドキュメントのために追加するのは下劣です。B

Shake documentationでこの問題に遭遇しています。例としてremoveFilesAfter、正しいリンクが得られません。

4

2 に答える 2

4

最初の質問 (なぜ? ) には部分的に答えることができます。それがバグなのか望ましい動作なのかはわかりません。

haddock が の参照を解決するときLexParseRn.rename、環境内の識別子を ( 経由で) 検索しようとしますlookupGRE_RdrName。これは失敗するはずです。次に、それが何を意味するかを調べます ( dataTcOccsGHC のRnEnvを使用)。関連する行は次のとおりです。

dataTcOccs :: RdrName -> [RdrName]
-- Return both the given name and the same name promoted to the TcClsName
-- namespace.  This is useful when we aren't sure which we are looking at.
dataTcOccs rdr_name
  [...]
  | isDataOcc occ || isVarOcc occ
  = [rdr_name, rdr_name_tc]
  [...]
  where
    occ = rdrNameOcc rdr_name
    rdr_name_tc = setRdrNameSpace rdr_name tcName

そのため、最初に以前と同じように解釈された名前 (おそらく値へのリンク) を返し、次に型コンストラクターとして解釈されます。通常の名前をどのようにして型コンストラクターにすることができますか? 私の推測では、これは TypeOperators が GHC 7.6 で改良されたときに追加されたもので、現在では値レベルの演算子と名前空間を共有しています。

次に、結果に対して haddock が一致します。最初のものが型コンストラクターである場合はそれを使用し、そうでない場合は 2 番目を使用します。したがって、以前は型コンストラクターであった場合、これが使用されます。またはそうではなく、 によって生成された修正バージョンdataTcOccsが使用されます。

haddock はここで常に最初のオプションを使用する必要があるように思われます。コードは、実際に解決できる場合に複数の結果が使用される方法から誤解を招くコピーにすぎません。

于 2013-07-29T08:21:09.390 に答える
2

これはHaddock のバグ #228と Neil のHaddock のバグ #253であり、修正は数か月前からアップストリームにありました。GHC HEAD をビルドしてドキュメントを再構築するか、7.8 を待ってから行うことができます。

于 2014-01-13T09:44:06.217 に答える