LLVM Bug生命周期¶
简介 - 在我们处理 Bug 报告时实现一致性¶
我们的目标是在已报告 Bug 从被报告、到被处理，最终到被关闭的过程中，实现基本的一致性水平。这种一致性有助于报告者、开发者和其他人更好地理解特定 Bug 状态的实际含义以及接下来可能发生的事情。
同时，我们的目标是不过度指定 LLVM Bug 跟踪系统 中 Bug 的生命周期，因为总体目标是使其更容易处理和理解 Bug 报告。
此处记录的生命周期的主要部分是
此外，Bug 跟踪器中的一些元数据，例如我们使用的标签，需要维护。请参阅以下内容了解详细信息
报告 Bug¶
有关如何提交好的 Bug 报告的更多详细信息，请参阅 如何提交 LLVM Bug 报告。
您可以将 标签 应用于 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。如果您认为这是一个适合 LLVM 新手修复的好 Bug，请添加
good first issue标签。此标签会添加到新贡献者的登陆页面。如果您不确定标签的预期用途，请参阅我们的标签文档。
积极致力于修复 Bug¶
如果您正在积极致力于修复 Bug，请记住将 Bug 分配给自己，并在您不再积极处理它时取消分配。您可以通过从 Assignees 字段中删除人员来取消分配 Bug。
解决/关闭 Bug¶
解决 Bug 是一件好事！请确保正确记录解决的原因。解决原因的示例包括
如果问题已通过特定提交解决，请关闭问题，并简要评论提及哪些提交修复了它。如果您自己编写修复程序，则您的 git 提交消息可能在单独一行上包含短语
Fixes #<issue number>。GitHub 识别此类提交消息，并将自动关闭指定的 issue，并引用您的提交。如果报告的行为不是 Bug，则适合关闭问题，并评论解释您为什么认为这不是 Bug，并添加
invalid标签。如果 Bug 与另一个 issue 重复，请将其关闭为重复项，方法是添加
duplicate标签，并评论指向它重复的 issue。如果有充分的理由不修复该问题（困难、ABI、开放的研究问题等），请添加
wontfix标签，并评论解释为什么预计不会进行任何更改。如果有一个具体且合理的理由认为给定的 Bug 在其他方面不适用或已过时。一个例子是未包含足够信息以清楚理解所报告问题的打开 Bug（例如，不可重现）。可以关闭此类 Bug，添加
worksforme标签，并留下评论，鼓励报告者在问题仍然可以重现时重新打开 Bug 并提供更多信息。
维护元数据¶
对项目具有写入权限的项目成员可以创建新标签，但我们不鼓励添加临时标签，因为我们希望控制标签的扩散并避免一次性标签。如果您希望添加新标签，请打开一个 issue，请求创建 issue 标签，并将 infrastructure 标签添加到该 issue。该请求应包括标签用途的描述。或者，您可以在 LLVM Discord 上的 #infrastructure 频道上请求创建标签。