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.
Hi! Here is a patch for #81859 that fix the vulnerabilities found in
gitpython, cryptography, urllib3 and requests.
I have just regenerated the requirements.txt files running pip-compile
again. Fortunately, this was enough to set all the dependencies on safe
versions.
I have also checked if new vulnerabilities were introduced by running
scorecard on my fork, but none has been introduced.
Thanks!
Signed-off-by: Joyce Brum <joycebrum@google.com>
Actions triggered by pull_request_target events have access to all
repository secrets, so it is unsafe to use them when executing untrusted
code. The pr-code-format workflow does not execute any untrusted code,
but it passes untrused input into clang-format. An attacker could use
this to exploit a flaw in clang-format and potentially gain access to
the repository secrets.
By splitting the workflow, we can use the pull_request target which is
more secure and isolate the issue write permissions in a separate job.
The pull_request target also makes it easier to test changes to the
code-format-helepr.py script, because the version of the script from the
pull request will be used rather than the version of the script from
main.
Fixes#77142
The answer to many requests in issues to be assigned to users is often
"just create a pull request". That's in contradiction to the
"introductory issue" instructions posted by the GitHub bot.
This change updates the instructions, mentioning the shortcut of "just
creating a PR". Moreover, it now explains linking PRs to issues in order
to close them automatically upon merge.
This makes it possible to rebase the branch using the Web UI, which
makes it easier to manually merge the PRs. Manual merge is required when
squash merge won't preserve author information of the backport.
Follow-up from PR #83491. `Darker`'s configuration is ignored because of the way we invoke it - with an explicit list of files. We need to filter it in `code-format-helper.py`.
When a backport request is made, the resulting pull request will have a
title like this:
<release branch>: <First line of HEAD commit for the branch>
And a body that says:
Backport <commit0> <commit1> ..
Requested By: <user>
