LLVM 錯誤生命週期¶
簡介 - 在處理錯誤報告方面實現一致性¶
我們的目標是在已回報的錯誤從被回報、到被處理、最終到被關閉的過程中，實現基本程度的一致性。這種一致性有助於回報者、開發人員和其他人更好地理解特定錯誤狀態的實際含義，以及預期接下來可能發生的事情。
同時，我們的目標是不過度規範 LLVM 錯誤追蹤系統 中錯誤的生命週期，因為總體目標是讓錯誤報告更易於使用和理解。
此處記錄的生命週期的主要部分是
此外，錯誤追蹤器中的一些元數據，例如我們使用的標籤，需要維護。詳情請參閱以下內容
回報錯誤¶
有關如何提交良好的錯誤報告的更多詳細資訊，請參閱 如何提交 LLVM 錯誤報告。
您可以將標籤應用於錯誤，以提供額外資訊，使錯誤更容易被發現，例如錯誤所屬專案部分的標籤。
錯誤分類¶
尚未標記 confirmed 標籤的未解決錯誤是仍需要分類的錯誤。當分類完成後，應新增 confirmed 標籤以及任何其他有助於對報告進行分類的標籤，除非問題正在被關閉。
分類錯誤的目標是確保新回報的錯誤最終處於良好、可操作的狀態。在分類時，請嘗試回答以下問題
回報的行為實際上是錯誤的嗎？
例如，編譯錯誤的範例是否取決於未定義的行為？
您可以根據報告中的詳細資訊重現錯誤嗎？
如果不能，是否有合理的解釋說明為什麼無法重現？
它是否與已回報的錯誤相關？
以下欄位是否已正確填寫？
標題
描述
標籤
如果可以，請新增適當的標籤來分類錯誤，例如工具（
clang、clang-format、clang-tidy等）或組件（backend:<name>、compiler-rt:<name>、clang:<name>等）。如果問題與特定版本的 C 或 C++ 標準有關，請新增適當的語言標準標籤（
c++20、c99等）。請不要同時使用通用標籤和特定標籤。例如，標記為
c++17的錯誤不應同時具有c++，而標記為clang:codegen的錯誤也不應同時具有clang。如果您認為這個錯誤適合 LLVM 新手修復，請新增
good first issue標籤。此標籤會連結到 新貢獻者的登陸頁面。如果您不確定標籤的用途，請參閱我們的標籤文件。
積極處理錯誤修復¶
如果您正在積極處理錯誤修復，請記得將錯誤指派給自己；當您不再積極處理時，請取消指派。您可以從 Assignees 欄位中移除人員來取消指派錯誤。
解決/關閉錯誤¶
解決錯誤是好的！請務必正確記錄解決原因。解決原因的範例包括
如果問題已透過特定提交解決，請關閉問題，並簡要註解提及哪些提交修復了它。如果您是自行撰寫修復程式碼，您的 git 提交訊息可以單獨在一行包含
Fixes #<issue number>字樣。GitHub 會識別此類提交訊息，並將自動關閉指定的 issue，並參考您的提交。如果回報的行為不是錯誤，則適合關閉 issue，並註解說明您認為它不是錯誤的原因，並新增
invalid標籤。如果錯誤與另一個 issue 重複，請將其關閉為重複項，方法是新增
duplicate標籤，並註解指向它重複的 issue。如果沒有修復問題的合理理由（困難、ABI、開放的研究問題等），請新增
wontfix標籤，並註解說明為什麼預期不會有任何變更。如果有特定且合理的理由認為給定的錯誤在其他方面不適用或已過時。一個例子是未解決的錯誤，其中不包含足夠的資訊來清楚理解所回報的問題（例如，無法重現）。可以關閉此類錯誤，新增
worksforme標籤，並留下註解以鼓勵回報者重新開啟錯誤，並提供更多資訊，如果錯誤對他們來說仍然可以重現。
維護元數據¶
具有專案寫入權限的專案成員可以建立新標籤，但我們不鼓勵新增臨時標籤，因為我們希望控制標籤的擴散並避免單次使用的標籤。如果您希望新增新標籤，請開啟一個 issue，要求建立 issue 標籤，並將 infrastructure 標籤新增至 issue。該請求應包括標籤用途的描述。或者，您可以在 LLVM Discord 上的 #infrastructure 頻道上要求建立標籤。