Add a new target "ninja clippy" for Rust projects #13914
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
bonzini
force-pushed
the
clippy
branch
2 times, most recently
from
9b4a5e0
to
cb0a22f
Compare
dcbaker
requested changes
Nov 18, 2024
dcbaker
approved these changes
Nov 19, 2024
|
A couple of the CI failures could be cleared up with a rebase but the mypy lint workflow is also failing and that doesn't look like something external to this PR. |
|
Hmm, it's a problem with TypedDict... Looks like I will have to make machine |
|
@bonzini you can using |
dcbaker
approved these changes
Nov 19, 2024
|
Thanks, and sorry for confusing the mypy failure with the msys ones. |
|
Restarting a potentially flaky job... |
eli-schwartz
requested changes
Nov 20, 2024
| return 0 | ||
|
|
||
| try: | ||
| await complete_all(futures) |
There was a problem hiding this comment.
... which leaves us with this as the one obviously useful import from mtest.py, which should potentially be refactored instead?
There was a problem hiding this comment.
Or moved to utils, but I think a one-off is okay since these are the two places that use asyncio in Meson.
bonzini
force-pushed
the
clippy
branch
5 times, most recently
from
b0a0c16
to
675d0b0
Compare
This was referenced Nov 20, 2024
Buffering the output of clang-tidy will kill colored output, because the tools being run are not going to see isatty() return true anymore. To avoid that, pass b_colorout down to the clangtidy script. As a bonus, this fixes -Db_colorout=never which was producing colored output from clang-tidy. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Differentiate from the "run_tool_on_targets" function that will be introduced in the next commit. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It is useful to apply a limit to the number of processes even outside "meson test", and specifically for clang tools. In preparation for this, generalize determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This improves the handling of keyboard interrupt, and also makes it easy to buffer the output and not mix errors from different subprocesses. This is useful for clang-tidy and will be used by clippy as well. In addition, the new code supports MESON_NUM_PROCESSES. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There is no need to create and look up a dictionary when MachineChoice is an enum, and there is no need to create a PerMachine object on every __setitem__ of another PerMachine object. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Even though the "targets" introspection info already includes the command line arguments used to invoke the compiler, this is not enough to correlated with the "compilers" introspection info and get extra information from there. Together with the existing "language" key, adding a "machine" key is enough to identify completely an entry in the compilers info. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Similar to the "ninja scan-build" target for C, add a clippy internal tool that runs clippy-driver on all crates in the project. The approach used is more efficient than with "ninja scan-build", and does not require rerunning Meson in a separate build directory; it uses the introspection data to find the compiler arguments for the target and invokes clippy-driver with a slightly modified command line. This could actually be applied to scan-build as well, reusing the run_tool_on_targets() function. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a target that builds all crates that could be extern to others, and then reruns clippy. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
clippy-driver is not meant to be a general-purpose compiler front-end. Since Meson can now provide natively the ability to invoke clippy, raise a warning if someone uses it that way. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Running clippy by setting a custom rustc compiler that points to "clippy-driver" is suboptimal, because it requires reconfiguration. Similar to the "ninja scan-build" target for C, add a clippy internal tool that runs clippy-driver on all crates in the project.
This also provide infrastructure to find sibling tools to rustc, such as "clippy-driver" itself or rustdoc, when using the "rustup run TOOLCHAIN rustc" to invoke rustc. Adding rustfmt for example is trivial.
A few extra new features are included as a bonus 👼
MESON_NUM_PROCESSESrespected every time Meson invokes multiple processes in parallel (supersedesMESON_TESTTHREADSb_coloroutmachineentry for each sources group, allowing cross lookup from targets to compilers