LLVM 错误生命周期¶
简介 - 如何以一致的方式处理错误报告¶
我们的目标是在处理错误报告时，从报告、处理到最终关闭，都保持基本的一致性。这种一致性有助于报告者、开发人员和其他人更好地理解特定错误状态的实际含义以及接下来可能发生的情况。
同时，我们的目标不是过度规范LLVM 错误跟踪系统中错误的生命周期，因为总体目标是使其更易于使用和理解错误报告。
此处记录的生命周期的主要部分是
此外，错误跟踪器中的一些元数据，例如我们使用的标签，需要维护。有关详细信息，请参阅以下内容
报告错误¶
有关如何提交良好的错误报告的更多详细信息，请参阅如何提交 LLVM 错误报告。
您可以对错误应用标签，以提供额外信息，使错误更容易被发现，例如与错误相关的项目部分的标签。
分类错误¶
未标记为已确认标签的开放错误是仍需要分类的错误。分类完成后，应添加已确认标签以及任何其他有助于对报告进行分类的标签，除非问题正在被关闭。
错误分类的目标是确保新报告的错误最终处于良好、可操作的状态。在分类时，请尝试回答以下问题
报告的行为真的错了吗？
例如，错误编译的示例是否取决于未定义的行为？
您是否可以从报告的详细信息中重现该错误？
如果不能，是否有合理的解释说明为什么无法重现？
它是否与已报告的错误有关？
以下字段是否已正确填写？
标题
描述
标签
如果可以的話，請添加適當的標籤來分類錯誤，例如工具（
clang、clang-format、clang-tidy等）或組件（backend:<名稱>、compiler-rt:<名稱>、clang:<名稱>等）。如果問題與 C 或 C++ 標準的特定版本有關，請添加適當的語言標準標籤（
c++20、c99等）。請不要同時使用通用標籤和特定標籤。例如，標記為
c++17的錯誤不應同時具有c++標籤，而標記為clang:codegen的錯誤不應同時具有clang標籤。如果您認為這是 LLVM 新手適合修復的錯誤，請添加
good first issue標籤。此標籤會連結到 新貢獻者的登陸頁面。如果您不確定標籤的用途，請參閱 我們的標籤文件。
積極修復錯誤¶
請記住，如果您正在積極修復錯誤，請將錯誤分配給自己；當您不再積極處理錯誤時，請取消分配。您可以透過從 Assignees 欄位中移除人員來取消分配錯誤。
解決/關閉錯誤¶
解決錯誤是件好事！請務必正確記錄解決原因。解決原因的範例包括：
如果問題已由特定提交解決，請關閉問題，並附上簡短的註解，說明哪些提交修復了該問題。如果您是自己撰寫修復程式碼，則您的 Git 提交訊息可以在單獨一行中包含
Fixes #<問題編號>。GitHub 會識別此類提交訊息，並使用提交的參考自動關閉指定的問題。如果報告的行為不是錯誤，則可以使用註解關閉問題，說明您認為它不是錯誤的原因，並添加
invalid標籤。如果錯誤與另一個問題重複，請透過添加
duplicate標籤並附上指向重複問題的註解，將其關閉為重複問題。如果有充分的理由不修復問題（例如難度、ABI、開放研究問題等），請添加
wontfix標籤，並附上註解說明為何預期不會有任何變更。如果有具體且合理的理由認為給定的錯誤不適用或已過時，則可以關閉該錯誤。例如，一個開放的錯誤沒有包含足夠的信息來清楚地理解報告的問題（例如不可重現）。可以關閉這樣的錯誤，並添加
worksforme標籤，並留下註解，鼓勵報告者在問題仍然可以重現時，使用更多信息重新打開錯誤。
維護中繼資料¶
具有專案寫入權限的專案成員可以建立新的標籤，但不鼓勵新增臨時標籤，因為我們希望控制標籤的擴散並避免單次使用的標籤。如果您想新增新標籤，請提出一個問題，要求建立問題標籤，並將 infrastructure 標籤新增至該問題。請求應包含標籤用途的說明。或者，您也可以在 LLVM Discord 的 #infrastructure 頻道上要求建立標籤。