Lines Matching +full:- +full:- +full:issue +full:- +full:number

10 Introduction - Achieving consistency in how we deal with bug reports
19 At the same time, we aim to not over-specify the life cycle of bugs in
20 `the LLVM Bug Tracking System <https://github.com/llvm/llvm-project/issues>`_,
44 …pply `labels <https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing…
56 unless the issue is being :ref:`closed<Closing>`.
78   such as the tool (``clang``, ``clang-format``, ``clang-tidy``, etc) or
79   component (``backend:<name>``, ``compiler-rt:<name>``, ``clang:<name>``, etc).
81 * If the issue is with a particular revision of the C or C++ standard, please
88 * Add the ``good first issue`` label if you think this would be a good bug to
90   for new contributors <https://github.com/llvm/llvm-project/contribute>`_.
93   `documentation for our labels <https://github.com/llvm/llvm-project/labels>`_.
112   * If the issue has been resolved by a particular commit, close the issue with
115     ``Fixes #<issue number>`` on a line by itself. GitHub recognizes such commit
116     messages and will automatically close the specified issue with a reference
119   * If the reported behavior is not a bug, it is appropriate to close the issue
123   * If the bug duplicates another issue, close it as a duplicate by adding the
124     ``duplicate`` label with a comment pointing to the issue it duplicates.
126   * If there is a sound reason for not fixing the issue (difficulty, ABI, open
145 labels and avoid single-use labels. If you would like a new label added, please
146 open an issue asking to create an issue label and add the ``infrastructure``
147 label to the issue. The request should include a description of what the label