PyGithub deprecated this a while back. An earlier patch attempted to fix
all the deprecations, but it looks like my grep expression missed a
bunch of cases. This patch should catch the remaining ones (minus libc++
which have been split for review by libc++ maintainers).
skip-precommit-approval label is intended for simple PR that don't
require approval. To reduce the volume of notifications, avoid sending
notifications to subscribers for PRs labeled as such.
This commit introduces a new `LintHelper` class to
`llvm/utils/git/code-lint-helper.py`, which lays the groundwork for
integrating additional linters (`doc8`) into Github Action workflow.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
This ensures that we are not including any branches on main that are not
in the current user's branch in the diff. We can add this to the command
now that --diff_from_common_commit (or at least the fixed version) has
landed in a release (21.1.1).
This PR updates the links used to show the PR contribution stats of the
user requesting commit access to the LLVM project. Previously we would
only show the PRs that were currently opened by the user because the
`/pulls/<username>` endpoint automatically applies the `is:open` filter.
The contribution guidelines suggest that the user should have at least 3
merged PRs to be considered for commit access so this seems like a
relevant data point to add.
We now show all PRs that a user has created (not just the open ones) and
a separate link for the PRs that are merged.
**KEY POINTS**
- MVP workflow to automatically lint C++ files, located **only** in
`clang-tools-extra/clang-tidy`. It's chosen this way as
`clang-tools-extra/clang-tidy` is almost 100% `clang-tidy` complaint,
thus we would automatically enforce a [high quality standard for
clang-tidy source
code](https://discourse.llvm.org/t/rfc-create-hardened-clang-tidy-config-for-clang-tidy-directory/87247).
(https://github.com/llvm/llvm-project/pull/147793)
- Implementation is very similar to code-format job, but without the
ability to run `code-lint-helper.py` locally.
**FOUND ISSUES** + open questions
- Speed: it takes ~ 1m40sec to download and unpack `clang-tidy` plus
additional ~4 mins to configure and CodeGen targets. I see that
`premerge.yaml` runs on special `llvm-premerge-linux-runners` runners
which can use `sccache` for speed. Can we use the same runners for this
job? Exact timings can be found
[here](https://github.com/llvm/llvm-project/actions/runs/17135749067/job/48611150680?pr=154223).
**TO DO**
- Place common components from `code-lint-helper.py` and
`code-format-helper.py` into a separate file and reuse it in both CI's.
- Compute CodeGen targets based on `projects_to_build`, for now
`clang-tablegen-targets` is hardcoded for `clang-tools-extra/`.
- Automatically generate and upload `.yaml` for
`clang-apply-replacements`
- Create an RFC with a plan how to enable `clang-tidy` in other projects
so that Maintainers of LLVM components could choose if they want
`clang-tidy` or not.
- Add more linters like `pylint`, `ruff` in the future.
This patch makes it so the revisions that the code format action returns
in its reproducers actually work when applying them locally given the
differences in how revisions are setup in CI.
Fixes#154294
New contributors can just indicate that they are working on the issue
without requesting assignment.
That shouldd reduce the burden of assigned issues that are not actually
being worked on, and new contributors waiting for a maintainer to
asssign them the issue.
---------
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
This script is not working any more in the GitHub actions jobs and I
can't reproduce this locally, so I've added some debug output to try to
help find the problem.
In clang-format, OpenCL .cl file uses default C++ formatting. There are
many pull-requests in libclc project that change OpenCL files. It is
beneficial to enable clang-format for them in CI.
Only check for diffs containing "undef" in .ll files, this prevents
comments like `// We should not have undef values...` triggering the
undef checker bot.
It's common to use the /cherry-pick command on a PR to create a backport
request. However, this creates a lot of clutter in the LLVM Release
Status project, because we end up with two items in the project, one for
the original PR and one for the new PR.
This change will set the status of the original PR to Done once the new
PR (for the release branch) is created. This will save release managers
a lot of work of having to manually updated the status for PRs that
contain backport requests.
As discussed in
https://discourse.llvm.org/t/please-dont-use-undef-in-tests-part-2/83388,
this patch adds a comment to PRs that introduce new uses of undef.
It uses the the `git diff -S' command to find new uses, avoiding warning
about old uses. It further trims down with a regex to get only added (+)
lines.
The default mode does not provide a way to see the actual failure of the
formatters without modifying the code. Instead offer the user the option
to rerun with a `FORMAT_HOOK_VERBOSE=1` environment variable to print
the actual formatting diff.
This gets us the full list of users with commit access to
llvm/llvm-project rather than the list of people in the llvm-committers
team. This will ensure we are able everyone to track everyone with
commit access in case they receive access some other way.
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file
handles from
staying open unnecessarily.
Also remove a couple unused or unneeded `__future__` imports.
Followup to #90109.
In Microsoft, our automated scans are warning that LLVM has vulnerable
dependencies. Specifically:
* [CVE-2024-35195](https://nvd.nist.gov/vuln/detail/CVE-2024-35195) was
fixed in `requests` 2.32.0.
* [CVE-2024-37891](https://nvd.nist.gov/vuln/detail/CVE-2024-37891) was
fixed in `urllib3` 2.2.2.
I've updated LLVM's dependencies by running the following commands in
`llvm/utils/git`:
```
pip-compile --upgrade --generate-hashes --output-file=requirements.txt requirements.txt.in
pip-compile --upgrade --generate-hashes --output-file=requirements_formatting.txt requirements_formatting.txt.in
```
Note that for `requirements_formatting.txt` this adds
`--generate-hashes` (according to my vague understanding, it's highly
desirable and was already used for `requirements.txt`) and was locally
run within `llvm/utils/git` (changing the recorded command, which
apparently was originally run from the repo root - again,
`requirements.txt` was already being regenerated with a locally run
command, so this increases consistency).
I observe that this has updated the relevant components to pick up the
CVE fixes. Note that I am largely clueless in this area, so I hope that
(like #90109) no other changes will be necessary.
This script linkifies (i.e. makes clickable in the terminal) text that appears
to be a pull request or issue reference (e.g. #12345 or PR12345) or a
40-character commit hash (e.g. abc123). You can configure git to automatically
send the output of commands that pipe their output through a pager, such as
`git log` and `git show`, through this script by running this command from
within your LLVM checkout:
git config core.pager 'llvm/utils/git/linkify | pager'
The pager command is run from the root of the repository even if the git
command is run from a subdirectory, so the relative path should always work.
It requires OSC 8 support in the terminal. For a list of compatible terminals,
see https://github.com/Alhadis/OSC8-Adoption
Reviewers: MaskRay
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/103496
This patch ensures that the CI script controls which file extensions are
considered instead of letting git-clang-format apply its own filtering
rules. In particular, this properly handles libc++ extension-less
headers which were passed to git-clang-format, but then dropped by
the tool as having an unrecognized extension.
This is a second attempt to land 7620fe0d2d1e, which was reverted in
9572388 because it caused formatting not to be enforced for several patches.
The problem was that we'd incorrectly pass the extensions with additional
quoting to git-clang-format. The incorrect quoting has been removed in this
version of the patch.
This reverts commit 7620fe0d2d1e0257611c0ab0d96f3bf1bf7a1079.
This patch was causing some significant portion of code formatting jobs
to succeed when they should have failed. More investigation is needed.
Tracked in #97060.
This ensures that the CI script controls which file extensions are
considered instead of letting git-clang-format apply its own filtering
rules. In particular, this properly handles libc++ extension-less
headers which were passed to git-clang-format, but then dropped by that
tool as having an unrecognized extension.
