既知の問題

Doxygenは実際のコンパイラではなく、単なる字句解析器です。これは、ソースコード内のエラーを検出できないことを意味します。
Doxygenには組み込みのプリプロセッサがありますが、これはCプリプロセッサとは若干異なる動作をします。Doxygenは、ヘッダーファイルが多重インクルードから適切に保護されており、各インクルードファイルがスタンドアロンである（つまり、コンパイラエラーを引き起こすことなくソースファイルの冒頭に配置できる）ことを前提としています。これが真である限り（そしてこれは良い設計慣行です）、問題に遭遇することはないでしょう。
考えられるすべてのコード断片をテストすることは不可能であるため、有効なC/C++コードの一部が適切に処理されない可能性は十分にあります。そのような断片を見つけた場合は、Doxygenの解析機能を改善できるよう、私に送ってください。検索を絞り込むのに役立つよう、送っていただくコードの断片はできるだけ小さくしてください。
コード内に同じ名前の複数のクラス、構造体、または共用体がある場合、Doxygenは適切に動作しません。ただし、クラッシュするのではなく、同じ名前のクラスのうち1つを除くすべてを無視するはずです。
一部のコマンドは、他のコマンドの引数内では機能しません。たとえば、HTMLリンク（つまり、<A HREF="...">...</A>）内では、他のコマンド（他のHTMLコマンドを含む）は機能しません！セクション化コマンドは重要な例外です。
冗長なブレースがDoxygenを混乱させる場合があります。例えば
```
  void f (int);
```
は関数宣言として適切に解析されますが、
```
  const int (a);
```
は、構文のみが解析され、意味論は解析されないため、intという名前の関数宣言としても認識されます。冗長なブレースが次のように検出できる場合、
```
  int *(a[20]);
```
Doxygenはブレースを削除し、結果を正しく解析します。
ドキュメントに含まれるコード断片内のすべての名前がリンクに置き換えられるわけではありません（例えばSOURCE_BROWSER = YESを使用した場合）。また、オーバーロードされたメンバーへのリンクが間違ったメンバーを指す可能性があります。これは、各関数に対して生成される「参照元」リストにも当てはまります。

これは部分的に、現在のコードパーサーが十分にスマートではないためです。将来的には改善を試みます。しかし、これらの改善をもってしても、可能性のある曖昧さやコード断片が見つかるコンテキストに関する情報不足のため、すべてを対応するドキュメントに適切にリンクすることはできません。
クラスAに、すでにfという名前で同じ引数リストを持つメンバーが存在する場合、\relatesコマンドまたは\relatesalsoコマンドを使用して非メンバー関数fをクラスAに挿入することはできません。
現時点では、メンバーの特殊化に対するサポートは非常に限られています。特殊化されたテンプレートクラスも存在する場合にのみ機能します。
すべての特殊コマンドがRTFに適切に翻訳されるわけではありません。
dotのバージョン1.8.6（およびそれ以前のバージョンも）は適切なマップファイルを生成せず、Doxygenが生成するグラフが適切にクリック可能にならない原因となります。
PHPのみ: Doxygenは、すべてのPHPステートメント（つまりコード）が関数/メソッド内にラップされていることを要求します。そうでない場合、解析上の問題に遭遇する可能性があります。

協力方法

Doxygenの開発は、皆様からのご意見に大きく依存しています！

Doxygenを試す際は、ご意見（特定の機能が不足しているかなど）をお聞かせください。使用しないと判断された場合でも、その理由をお知らせください。

バグの報告方法

バグはGitHubのissue trackerで追跡されています。新しいバグを提出する前に、まず他のユーザーによって同じバグがすでに提出されていないかデータベースを検索してください。新しいバグを発見したと思われる場合は、報告してください。

何かがバグであるかどうか不明な場合は、まず（購読が必要な）ユーザーメーリングリスト、またはdoxygenタグを使用してStack Overflowでヘルプを求めてください。

バグの（漠然とした）説明のみを送付された場合、通常はあまり役に立たず、私が何を意図しているのかを理解するのに多くの時間がかかります。最悪の場合、バグレポートが私に完全に無視される可能性もありますので、バグレポートには常に以下の情報を含めるようにしてください。

使用しているDoxygenのバージョン（例: 1.5.3。不明な場合はdoxygen --version、さらに詳細な情報が必要な場合はdoxygen --Versionを使用してください）。
使用しているオペレーティングシステムの名前とバージョン番号（例: Ubuntu Linux 18.04 LTS）
設定ファイルも一緒に送っていただくのが通常良いですが、ファイルを小さく保つために、生成時にはDoxygenを-sフラグと一緒に使用してください（既存の設定ファイルからコメントを削除するにはdoxygen -s -u [configName]を使用します。使用している設定とDoxygenのデフォルト設定との違いを取得するには、使用している[configName]に対して-xまたは-x_noenvフラグを使用する方がさらに良いです。したがってdoxygen -x [configName]）。
私がバグを修正する最も簡単な（そしてしばしば唯一の）方法は、問題を示す小さなサンプルをバグレポートに添付していただき、私が自分のマシンでそれを再現できるようにすることです。サンプルが有効なソースコードであり（コンパイル可能であること）、そのサンプルによって問題が実際に再現されることを確認してください（実際のバグを誘発しないサンプルを受け取ることがよくあります！）。複数のファイルを送る場合は、処理を容易にするためにファイルをzipまたはtarでまとめて1つのファイルにしてください。新しいバグを報告する際、最初のバグの説明を提出した**後**にのみファイルを添付する機会が得られることに注意してください。
提出する前に、いくつかのデバッグフラグを使ってDoxygenを実行することも検討してください。すべてのフラグについてはdoxygen -dを実行してください。preprocessorオプションは、Doxygenが入力ファイルをどのように解釈しているかについてヒントを与えるかもしれません。

報告されたバグに対するパッチを追加することができます（そして推奨されます）。その場合、プルリクエストフォームのタイトルには「issue #NUMBER TITLE」を使用してください。「NUMBER」と「TITLE」は、GitHub上の関連するissueを参照します。

既存のバグや制限を修正する方法についてアイデアがある場合は、（購読が必要な）開発者メーリングリストで議論してください。バグトラッカーやメーリングリスト経由で送信したくない場合は、doxyg.nosp@m.en@g.nosp@m.mail..nosp@m.comに直接パッチを送ることもできます。

パッチには「diff -uN」を使用するか、変更したファイルを含めてください。複数のファイルを送る場合は、すべてをtarまたはzipでまとめてください。そうすれば、私が保存・ダウンロードするファイルが1つで済みます。

次のセクションへ進むか、インデックスに戻る。