user.login is the account name and user.name is an optional display name
(often their full name). I got an email generated from a colleague's PR
that said:
```
Author: None (<their username>)
```
As they hadn't set user.name in their account. Which isn't a problem,
but it would be neater if we didn't print None.
So I've added a helper function to handle that. If the user has set
both, the output is as it was before, if the user has not, we just show
the login name.
The login name can apparently be None too. In that case we'll print
"None" for it. This does not seem to be a common case though, and I'm
not sure printing anything else would be any more useful.
The motivator here is that Python allows class methods to be redefined.
But in the vast majority of cases this is a bug. E.g., in our API
test-suite two methods with the same name cause the latest definition to
shadow the earlier, in which case only one test-case runs. This happens
silently. Every couple of months i've been running the script from
https://github.com/llvm/llvm-project/pull/97043 manually on the
code-base and it catches a handful of these every time.
This patch sets up a github action that runs on pull requests that
change any files under `lldb/test/API`. The action runs `pylint` on the
changed Python files. The caveat here is that `pylint` isn't set up to
run cleanly on our test-suite. So I just use the [specific redefinition
error
code](https://pylint.readthedocs.io/en/stable/user_guide/messages/error/function-redefined.html).
Any other errors won't cause `pylint` to fail for now (hence the
`--error-under=0`).
Here's an example:
<img width="1412" height="367" alt="Screenshot From 2026-02-20 10-29-28"
src="https://github.com/user-attachments/assets/20093be8-a122-4e17-944a-4472eb12ab25"
/>
We should not need to be explicitly adding transitive dependencies to
requirements_formatting.txt.in to enforce a higher version is used. We
also should always be using == to ensure a strict version match, not
just a compatible version (~=). This patch removes transitive
dependencies introduced in 6fdf93c5d812197dd5dc9362f324b944105b2e8e and
updates the lockfile (although only unnecessary packages are removed).
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.
