LLVM Bug 生命周期¶
引言 - 实现处理 Bug 报告的一致性¶
我们的目标是在处理报告的 Bug 的过程中实现基本的一致性，从报告、处理到最终关闭。这种一致性有助于报告者、开发者和其他人员更好地理解特定 Bug 状态的实际含义以及接下来可能发生的事情。
同时，我们也希望避免在LLVM Bug 跟踪系统中过度规范 Bug 的生命周期，因为总体目标是简化 Bug 报告的使用和理解。
此处记录的生命周期主要部分包括：
此外，Bug 跟踪器中的一些元数据（例如我们使用的标签）也需要维护。请参阅以下内容了解详细信息：
报告 Bug¶
有关如何提交高质量 Bug 报告的更多详细信息，请参阅如何提交 LLVM Bug 报告。
您可以应用标签到 Bug 上，以提供额外的信息，使 Bug 更易于发现，例如与项目相关部分的标签。
分类 Bug¶
未标记为confirmed标签的开放 Bug 是仍然需要分类的 Bug。当分类完成后，应添加confirmed标签以及任何其他有助于对报告进行分类的标签，除非问题正在关闭。
分类 Bug 的目标是确保新报告的 Bug 处于良好的、可操作的状态。在分类时，请尝试回答以下问题：
报告的行为是否确实错误？
例如，编译错误示例是否依赖于未定义行为？
您能否根据报告中的详细信息重现 Bug？
如果不能，是否有合理的解释说明为什么无法重现？
它是否与已报告的 Bug 相关？
以下字段是否填写正确？
标题
描述
标签
在能够做到的时候，请添加适当的标签来对 Bug 进行分类，例如工具（
clang、clang-format、clang-tidy等）或组件（backend:<name>、compiler-rt:<name>、clang:<name>等）。如果问题与 C 或 C++ 标准的特定版本有关，请添加适当的语言标准标签（
c++20、c99等）。请勿同时使用通用标签和特定标签。例如，标记为
c++17的 Bug 不应同时具有c++标签，标记为clang:codegen的 Bug 不应同时具有clang标签。如果您认为此 Bug 非常适合 LLVM 新手修复，请添加
good first issue标签。此标签会提供给新贡献者着陆页。如果您不确定标签的用途，请参阅我们标签的文档。
积极修复 Bug¶
如果您正在积极修复 Bug，请记住将 Bug 分配给自己，并在不再积极处理时取消分配。您可以通过从Assignees字段中删除人员来取消分配 Bug。
解决/关闭 Bug¶
解决 Bug 是一件好事！请确保正确记录解决的原因。解决 Bug 的原因示例包括：
如果某个特定的提交解决了问题，请在关闭问题时添加简短的注释，说明哪个提交修复了它。如果您本人是修复的作者，您的 Git 提交消息可以包含
Fixes #<issue number>（一行）的字样。GitHub 会识别此类提交消息，并自动关闭指定的问题，并附上对您提交的引用。如果报告的行为不是 Bug，则可以添加注释说明您认为它不是 Bug 的原因，并添加
invalid标签，然后关闭问题。如果 Bug 重复了另一个问题，请添加
duplicate标签，并附上指向其重复问题的注释，然后关闭它。如果存在不修复问题的充分理由（难度、ABI、开放性研究问题等），请添加
wontfix标签，并添加注释解释为什么不期望进行更改。如果存在特定且合理的理由认为给定的 Bug 不适用或已过时。例如，一个开放的 Bug，其中包含的信息不足以清楚地理解报告的问题（例如，无法重现）。可以关闭此类 Bug，添加
worksforme标签，并留下评论鼓励报告者在 Bug 仍然对他们可重现的情况下，添加更多信息重新打开 Bug。
元数据维护¶
拥有项目写入权限的项目成员可以创建新的标签，但我们不鼓励添加临时标签，因为我们希望控制标签的扩散并避免单一用途的标签。如果您想添加新的标签，请打开一个问题请求创建问题标签，并向该问题添加infrastructure标签。请求应包括对标签用途的描述。或者，您可以在 LLVM Discord 的#infrastructure频道上请求创建标签。