貢獻 LLVM¶
感謝您對貢獻 LLVM 的興趣！有多種貢獻方式，我們感謝所有的貢獻。如果您有任何疑問，可以使用論壇，或如需更互動式的聊天，請前往我們的 Discord 伺服器。
如果您想貢獻程式碼，請先熟悉LLVM 開發者政策。
貢獻方式¶
錯誤報告¶
如果您在使用 LLVM 時遇到錯誤，我們絕對希望能知道。請告知我們，並依照如何提交 LLVM 錯誤報告中的指示建立錯誤報告。
錯誤修復¶
如果您有興趣貢獻程式碼給 LLVM，在錯誤追蹤器中，標記為 good first issue 關鍵字的錯誤，是熟悉程式碼庫的好方法。如果您有興趣修復錯誤，請在該錯誤上留言，讓其他人知道您正在處理。
然後嘗試使用上游 LLVM 重現並修復錯誤。首先依照 LLVM 系統入門 中的說明，從原始碼建置 LLVM，並使用建置好的二進位檔案來重現錯誤報告中描述的失敗情況。使用除錯建置 (-DCMAKE_BUILD_TYPE=Debug) 或啟用斷言的建置 (-DLLVM_ENABLE_ASSERTIONS=On，除錯建置預設啟用)。
回報安全漏洞¶
提交與安全性相關的錯誤有另一個獨立的流程，請參閱 如何回報安全漏洞？。
較大型的工作項目¶
如果您有興趣承擔較大型的工作項目，LLVM 的開放專案頁面維護了一個有趣的專案列表。如果您有興趣參與這些專案，請在論壇上發文，讓我們知道該專案正在進行中。
如何提交補丁¶
一旦您準備好補丁，就該提交了。補丁應該
包含一個小型的單元測試
符合 LLVM 程式碼規範。您可以使用 clang-format-diff.py 或 git-clang-format 工具自動正確地格式化您的補丁。
不包含任何不相關的變更
是一個獨立的變更。獨立的變更應作為個別的補丁提交，這樣可以更輕鬆地進行審查。
只有一個提交，與上游
origin/main分支同步，且沒有合併。
在發送補丁進行審查之前，也請盡力確保其格式正確。我們使用 clang-format 來進行格式化，它透過 git-clang-format 腳本與 git 整合。在某些系統上，它可能已經安裝（或可以透過您的套件管理器安裝）。如果是這樣，您可以直接執行它 – 以下命令將僅格式化最近一次提交中變更的程式碼
% git clang-format HEAD~1
注意
對於某些補丁，格式化它們可能會加入模糊補丁意圖的變更。例如，加入到先前未格式化的列舉可能會導致整個列舉被重新格式化。發生這種情況是因為並非所有 LLVM 專案目前都符合 LLVM 的 clang-format 風格。
如果您認為您的變更可能發生這種情況，或不確定，我們建議您將格式化變更作為獨立的提交加入到 Pull Request 中。
審查人員可能會要求將此格式化提交做成一個獨立的 Pull Request，該 Pull Request 將在您的實際變更之前合併。
這表示如果格式化變更是第一個提交，您將更容易做到這一點。如果不是，也沒關係，但您將需要做更多工作才能將其分開。
請注意，git clang-format 會修改檔案，但不會提交它們 – 您可能需要執行以下其中一個命令將變更加入到提交中
# To create a new commit.
% git commit -a
# To add to the most recent commit.
% git commit --amend -a
注意
如果您的系統上尚未安裝 clang-format 或 git clang-format，則 clang-format 二進位檔案將與 clang 一起建置，並且可以從 clang/tools/clang-format/git-clang-format 執行 git 整合。
LLVM 專案已遷移到 GitHub Pull Requests 作為其審查流程。有關使用 GitHub Pull Requests 工作流程的更多資訊，請參閱我們的 GitHub 文件。我們仍然有一個唯讀的 LLVM Phabricator 實例。
為了確保合適的人員看到您的補丁，請選擇合適的審查人員，並在請求審查時將他們加入到您的補丁中。
合適的審查人員是您正在修改的專案的維護者，以及任何在您的補丁觸及的領域工作的人員。要尋找維護者，請在專案子目錄的根目錄中尋找 Maintainers.md 或 Maintainers.rst 檔案。例如，LLVM 的是 llvm/Maintainers.md，而 Clang 的是 clang/Maintainers.rst。
如果您是新的貢獻者，您將無法以這種方式選擇審查人員，在這種情況下，您仍然可以透過在評論中 CC 他們來引起潛在審查人員的注意 – 只需 @name 他們即可。
如果您在一週內沒有收到關於您的補丁的評論，您可以透過在 GitHub PR 中使用 “Ping” 評論來請求審查。通常的禮貌性 ‘ping’ 頻率為每週一次。請記住，您正在要求其他專業開發人員的寶貴時間。
在您的 PR 獲得批准後，您可以合併它。如果您沒有合併 PR 的能力，請要求您的審查人員代表您合併。您必須明確地這樣做，因為審查人員的預設假設是您能夠合併自己的 PR。
有關 LLVM 程式碼審查流程的更多資訊，請參閱 LLVM 程式碼審查政策與實務。
供開發人員從 Git 提交變更¶
注意
另請參閱 GitHub，以取得有關將您的變更合併到 LLVM 專案單一儲存庫的更多詳細資訊。
一旦補丁經過審查，您就可以在 GitHub 網頁介面中選擇 “Squash and merge” 按鈕。
當直接從命令列推送到 main 分支時，您需要 rebase 您的變更。LLVM 具有線性歷史政策，這表示不允許合併提交，並且 main 分支配置為拒絕包含合併的推送。
GitHub 將顯示如下訊息
remote: Bypassed rule violations for refs/heads/main:
remote:
remote: - Required status check “buildkite/github-pull-requests” is expected.
這看起來可能很可怕，但這只是 GitHub 設定的人為產物：它旨在作為警告，提醒人們合併具有失敗 CI 的 pull-requests。我們無法為從命令列推送的人員禁用它。
如果您在特定的 git 工作流程中遇到問題，請尋求協助。
Git pre-push hook¶
我們包含一個可選的 pre-push hook，它會在您即將推送的修訂版本上執行一些健全性檢查，如果您一次推送多個提交，則會要求確認。您可以透過從儲存庫根目錄執行以下命令來設定它（在 Unix 系統上）
% ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push
關於 LLVM 的實用資訊¶
LLVM 文件提供了關於 LLVM 內部結構以及各種使用者指南的豐富資訊。下面列出的頁面應該可以很好地概述 LLVM 的高階設計及其內部結構
- LLVM 系統入門
討論如何快速啟動並執行 LLVM 基礎架構。從解壓縮和編譯發行版到執行某些工具的所有內容。
- LLVM 語言參考手冊
定義 LLVM 中間表示法。
- LLVM 程式設計師手冊
介紹 LLVM 原始碼庫的一般佈局、重要的類別和 API，以及一些提示和技巧。
- LLVM 給研究所學生
這是 Adrian Sampson 對 LLVM 基礎架構的介紹。雖然它是為研究所學生編寫的，但它提供了對 LLVM 架構、LLVM IR 以及如何編寫新 Pass 的良好、簡潔的概述。
- LLVM 簡介
提供編譯器駭客對 LLVM 的介紹的書籍章節。