既知の問題

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で追跡されます。新しいバグを送信する前に、まずデータベースを検索して、同じバグが他の人によって既に送信されていないか確認してください。新しいバグを見つけたと確信した場合は、報告してください。

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

バグの（曖昧な）説明だけを送信した場合、通常はあまり役に立たず、私があなたが何を意味するのか理解するのにさらに時間がかかります。最悪の場合、バグレポートは私によって完全に無視される可能性さえあります。そのため、常にバグレポートに次の情報を含めるようにしてください。

使用しているDoxygenのバージョン（たとえば1.5.3。不明な場合は doxygen --version を使用するか、もう少し詳しい情報が必要な場合は doxygen --Version を使用してください）。
オペレーティングシステムの名前とバージョン番号（例：Ubuntu Linux 18.04 LTS）
通常、構成ファイルも一緒に送信することをお勧めしますが、小さく保つために、生成中に -s フラグを付けてDoxygenを使用してください（既存の構成ファイルからコメントを削除するには doxygen -s -u [configName] を使用してください。さらに良いのは、使用した [configName] で -x または -x_noenv フラグを使用して、使用された設定とDoxygenのデフォルト設定の違いを取得することです。したがって、doxygen -x [configName] です）。
私がバグを修正する最も簡単な（そして多くの場合唯一の）方法は、バグレポートに問題を示す小さな例を添付してもらい、私が自分のマシンでそれを再現できるようにすることです。例が有効なソースコード（コンパイルできる可能性のある）であり、問題が実際に例によって捉えられていることを確認してください（私はしばしば実際のバグを引き起こさない例を受け取ります！）。複数のファイルを送信する場合は、処理を容易にするために、ファイルをzipまたはtarで単一のファイルにまとめてください。新しいバグを報告するときは、最初のバグの説明を送信した*後*にのみ、ファイルを添付する機会が得られることに注意してください。
送信する前に、いくつかのデバッグフラグを付けて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つだけにしてください。

次のセクションに進むか、インデックスに戻ります。