-
Notifications
You must be signed in to change notification settings - Fork 13.4k
use problem matchers for tidy CI #106085
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
use problem matchers for tidy CI #106085
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
e0edc43
to
88889c1
Compare
This comment has been minimized.
This comment has been minimized.
77424db
to
7e29713
Compare
See this to confirm that it is working correctly. |
The duplication is unfortunate... tidy should (?) be the same across jobs, can we collect annotations only from one of them? |
It might be best to only run tidy on |
I believe some parts of tidy are platform specific (e.g., checking binaries/executable files checked into tree). I'm not sure if there's anything else like that. |
I checked that part of tidy and it looks like it only runs on unix systems and it just checks if there are files marked as executable. |
Yeah let's only run tidy in its dedicated job to remove the duplicate annotations. |
I've pushed a commit to not run tidy on x86_64-gnu-llvm-13, which should resolve this. |
@pietroalbini @Mark-Simulacrum any updates? |
@bors r+ |
📌 Commit ab8b63f3abfaaee85ba5d928b56c0eb4541ef4fb has been approved by It is now in the queue for this repository. |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
ab8b63f
to
a2040de
Compare
Rebased. @bors r=pietroalbini |
…, r=pietroalbini use problem matchers for tidy CI
…, r=pietroalbini use problem matchers for tidy CI
…, r=pietroalbini use problem matchers for tidy CI
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#105798 (Relax ordering rules for `asm!` operands) - rust-lang#105962 (Stabilize path_as_mut_os_str) - rust-lang#106085 (use problem matchers for tidy CI) - rust-lang#107711 (Stabilize movbe target feature) - rust-lang#108017 (Add `--no-undefined-version` link flag and fix associated breakage) - rust-lang#108891 (Remove an extraneous include) - rust-lang#108902 (no more do while :<) - rust-lang#108912 (Document tool lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#105798 (Relax ordering rules for `asm!` operands) - rust-lang#105962 (Stabilize path_as_mut_os_str) - rust-lang#106085 (use problem matchers for tidy CI) - rust-lang#107711 (Stabilize movbe target feature) - rust-lang#108017 (Add `--no-undefined-version` link flag and fix associated breakage) - rust-lang#108891 (Remove an extraneous include) - rust-lang#108902 (no more do while :<) - rust-lang#108912 (Document tool lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This also fixes a regression from rust-lang#106085 which stopped testing that we support python2 in PR CI.
…lacrum Add tests for configure.py I highly recommend reviewing this with whitespace disabled. Notably, verifying that we generate valid toml relies on python 3.11 so we can use `tomllib`, so this also switches`x86_64-gnu-llvm-14` (one of the PR builders) to use 3.11. While fixing that, I noticed that we stopped testing python2.7 support on PR CI in rust-lang#106085. `@fee1-dead` `@pietroalbini` please be more careful in the future, there is no CI for CI itself that verifies we are testing everything we should be. - Separate out functions so that each unit test doesn't create a file on disk - Add a few unit tests
Like rust-lang#107044, this will let us track compatibility with LLVM 16 going forward, especially after we eventually upgrade our own to the next. This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with that change in rust-lang#106085.
…lacrum ci: add a runner for vanilla LLVM 16 Like rust-lang#107044, this will let us track compatibility with LLVM 16 going forward, especially after we eventually upgrade our own to the next. This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with that change in rust-lang#106085.
No description provided.