LLVM 贡献指南¶
感谢您对 LLVM 贡献的兴趣！有多种贡献方式，我们感谢所有的贡献。如果您有任何疑问，您可以使用论坛，或者进行更具互动性的聊天，请访问我们的Discord 服务器。
如果您想贡献代码，请先熟悉LLVM 开发者策略。
贡献方式¶
错误报告¶
如果您在使用 LLVM 时遇到错误，我们非常希望了解。请告知我们，并按照如何提交 LLVM 错误报告中的说明创建错误报告。
错误修复¶
如果您有兴趣为 LLVM 贡献代码，标有 good first issue 关键字的 bug tracker 中的错误是熟悉代码库的好方法。如果您有兴趣修复错误，请在上面评论，让人们知道您正在处理它。
然后尝试使用上游 LLVM 重现并修复该错误。首先按照LLVM 系统入门中的描述从源代码构建 LLVM，并使用构建的二进制文件重现错误报告中描述的故障。使用调试构建 (-DCMAKE_BUILD_TYPE=Debug) 或启用断言的构建 (-DLLVM_ENABLE_ASSERTIONS=On，调试构建默认启用)。
报告安全问题¶
提交安全相关错误有一个单独的流程，请参阅如何报告安全问题？。
更大的工作¶
如果您有兴趣承担更大的工作，LLVM 的开放项目页面上维护着一份有趣的项目列表。如果您有兴趣参与这些项目中的任何一个，请在论坛上发帖，以便我们知道该项目正在被处理。
如何提交补丁¶
一旦您准备好补丁，就可以提交了。补丁应该
包含一个小的单元测试
符合LLVM 编码标准。您可以使用clang-format-diff.py 或 git-clang-format 工具自动正确地格式化您的补丁。
不包含任何无关的更改
是一个独立的更改。独立的更改应作为单独的补丁提交，因为这使得审查更容易。
只有一个 commit，与上游
origin/main分支保持最新，并且没有合并。
在发送补丁进行审查之前，请尽量确保其格式正确。我们使用 clang-format 来实现这一点，它通过 git-clang-format 脚本集成了 git。在某些系统上，它可能已经安装（或者可以通过您的软件包管理器安装）。如果是这样，您可以直接运行它 – 以下命令将仅格式化最近的 commit 中更改的代码
% git clang-format HEAD~1
注意
对于某些补丁，格式化它们可能会添加掩盖补丁意图的更改。例如，添加到以前未格式化的枚举可能会导致整个枚举被重新格式化。发生这种情况是因为并非所有 LLVM 项目都符合目前 LLVM 的 clang-format 风格。
如果您认为您的更改可能是这种情况，或者不确定，我们建议您将格式化更改作为 单独的 commit 添加到 Pull Request 中。
审查人员可能会要求将此格式化 commit 制作成单独的 Pull Request，该 Pull Request 将在您的实际更改之前合并。
这意味着如果格式化更改是第一个 commit，您将更容易做到这一点。如果不是，也没关系，但您将需要做更多的工作来将其分离出来。
请注意，git clang-format 修改文件，但不提交它们 – 您可能需要运行以下命令之一将更改添加到 commit
# 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 他们。
如果您在一个星期内没有收到关于您的补丁的评论，您可以通过在评论中使用“Ping”来“ping”GitHub PR 来请求审查。常见的礼貌性 “ping” 频率为每周一次。请记住，您正在向其他专业开发人员索取宝贵的时间。
在您的 PR 获得批准后，您可以合并它。如果您没有合并 PR 的能力，请让您的审查人员代表您合并它。您必须明确地这样做，因为审查人员的默认假设是您能够合并自己的 PR。
有关 LLVM 代码审查流程的更多信息，请参阅LLVM 代码审查策略和实践。
供开发者从 Git 提交更改¶
注意
另请参阅GitHub，了解有关将您的更改合并到 LLVM 项目 monorepo 中的更多详细信息。
补丁经过审查后，您可以选择 GitHub Web 界面中的 “Squash and merge” 按钮。
当直接从命令行推送到 main 分支时，您需要 rebase 您的更改。LLVM 具有线性历史策略，这意味着不允许合并 commit，并且 main 分支配置为拒绝包含合并的推送。
GitHub 将显示如下消息
remote: Bypassed rule violations for refs/heads/main:
remote:
remote: - Required status check “buildkite/github-pull-requests” is expected.
这看起来可能很可怕，但这只是 GitHub 设置的一个产物：它旨在作为对合并具有失败 CI 的 pull-request 的人员的警告。我们无法为在命令行上推送的人员禁用它。
如果您在特定的 git 工作流程中遇到问题，请寻求帮助。
Git pre-push 钩子¶
我们包含一个可选的 pre-push 钩子，它对您即将推送的修订版本运行一些健全性检查，并在您一次推送多个 commit 时请求确认。您可以通过从存储库根目录运行以下命令来设置它（在 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 简介。