[PATCH] rust: restrict missing_const_for_fn to qemu_api crate

[PATCH] rust: restrict missing_const_for_fn to qemu_api crate

[Paolo Bonzini]

missing_const_for_fn is not necessarily useful or good.  For example in
a private API you can always add const later, and in a public API
it can be unnecessarily restrictive to annotate everything with const
(blocking further improvements to the API).

Nevertheless, QEMU turns it on because qemu_api uses const quite
aggressively and therefore it can be handy to have as much as possible
annotated with const.  Outside qemu_api though, not so much: devices
are self contained consumers and if there is nothing that could use
their functions in const contexts that were not anticipated.

Since missing_const_for_fn can be a bit noisy and trigger on trivial
functions that no one would ever call in const context, do not
turn it on everywhere and only keep it in qemu_api as a special case.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 rust/Cargo.toml          | 1 -
 rust/qemu-api/src/lib.rs | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/rust/Cargo.toml b/rust/Cargo.toml
index 5b6b6ca4382..5b0cb559286 100644
--- a/rust/Cargo.toml
+++ b/rust/Cargo.toml
@@ -52,7 +52,6 @@ empty_structs_with_brackets = "deny"
 ignored_unit_patterns = "deny"
 implicit_clone = "deny"
 macro_use_imports = "deny"
-missing_const_for_fn = "deny"
 missing_safety_doc = "deny"
 multiple_crate_versions = "deny"
 mut_mut = "deny"
diff --git a/rust/qemu-api/src/lib.rs b/rust/qemu-api/src/lib.rs
index bfb6c6d6e42..20134d75ce5 100644
--- a/rust/qemu-api/src/lib.rs
+++ b/rust/qemu-api/src/lib.rs
@@ -4,6 +4,8 @@
 
 #![cfg_attr(not(MESON), doc = include_str!("../README.md"))]
 
+#![deny(clippy::missing_const_for_fn)]
+
 #[rustfmt::skip]
 pub mod bindings;
 
-- 
2.48.1

Re: [PATCH] rust: restrict missing_const_for_fn to qemu_api crate

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 9:40 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> missing_const_for_fn is not necessarily useful or good.  For example in
> a private API you can always add const later, and in a public API
> it can be unnecessarily restrictive to annotate everything with const
> (blocking further improvements to the API).
>
> Nevertheless, QEMU turns it on because qemu_api uses const quite
> aggressively and therefore it can be handy to have as much as possible
> annotated with const.  Outside qemu_api though, not so much: devices
> are self contained consumers and if there is nothing that could use
> their functions in const contexts that were not anticipated.
>
> Since missing_const_for_fn can be a bit noisy and trigger on trivial
> functions that no one would ever call in const context, do not
> turn it on everywhere and only keep it in qemu_api as a special case.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>