On 11/13/24 08:14, Junjie Mao wrote:
Paolo Bonzini <pbonz...@redhat.com> writes:
Many lints that default to allow can be helpful in detecting bugs or
keeping the code style homogeneous. Add them liberally, though perhaps
not as liberally as in hw/char/pl011/src/lib.rs. In particular, enabling
entire groups can be problematic because of bitrot when new links are
added in the future.
For Clippy, this is actually a feature that is only present in Cargo
1.74.0 but, since we are not using Cargo to *build* QEMU, only developers
will need a new-enough cargo and only to run tools such as clippy.
The requirement does not apply to distros that are building QEMU.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
rust/Cargo.toml | 66 +++++++++++++++++++++++++++++++++++
rust/hw/char/pl011/src/lib.rs | 18 ++--------
rust/qemu-api/src/bindings.rs | 6 ++--
3 files changed, 71 insertions(+), 19 deletions(-)
diff --git a/rust/Cargo.toml b/rust/Cargo.toml
index 1ff8f5c2781..43cca33a8d8 100644
--- a/rust/Cargo.toml
+++ b/rust/Cargo.toml
@@ -19,3 +19,69 @@ unknown_lints = "allow"
# Prohibit code that is forbidden in Rust 2024
unsafe_op_in_unsafe_fn = "deny"
+
[snip]
+
+# nice to have, but cannot be enabled yet
+#wildcard_imports = "deny"
+
+# these may have false positives
+#option_if_let_else = "deny"
+cognitive_complexity = "deny"
Just to confirm, CC <= 25 is to be enforced for all methods, right?
I wanted an opinion on that. option_if_let_else has been more of a pain
than a benefit, sometimes it suggests code that is worse or does not
even compile.
So far I've never had any cognitive_complexity error show up, but pl011
used it so I have kept it in Cargo.toml. If we start having too many
#[allow()] for cognitive_complexity we can remove it; for many of the
others, instead, we might even change deny to forbid.
Paolo
