tokio-rs / axum

Ergonomic and modular web framework built with Tokio, Tower, and Hyper
19.03k stars 1.06k forks source link

`FromRef` triggers `clippy::clone_of_ref_ptr` #2826

Closed AlphaKeks closed 3 months ago

AlphaKeks commented 3 months ago

Bug Report

Version

0.7.5

Platform

Linux 6.6.34 #1-NixOS SMP PREEMPT_DYNAMIC Sun Jun 16 11:47:49 UTC 2024 x86_64 GNU/Linux

Description

When deriving FromRef, clippy will trigger clippy::clone_on_ref_ptr. This lint is allow-by-default, which is probably why nobody reported it yet.

You can reproduce the issue by adding axum@0.7.5 as a dependency with the macros feature enabled, and writing the following code:

use std::sync::Arc;

use axum::extract::FromRef;

#[derive(Clone, FromRef)]
pub struct MyState {
    substate: Arc<MySubstate>,
}

pub struct MySubstate {}

And then running clippy with the offending lint set to warn (or higher):

$ cargo clippy -- -Wclippy::clone_on_ref_ptr

warning: using `.clone()` on a ref-counted pointer
 --> src/lib.rs:7:12
  |
7 |     substate: Arc<MySubstate>,
  |               ^^^ help: try: `Arc::<MySubstate>::clone(&substate: Arc)`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_ref_ptr
  = note: requested on the command line with `-W clippy::clone-on-ref-ptr`

I would assume adding a clippy::clone_on_ref_ptr to the #[allow(…)] attribute on this line would fix the problem. I can open a PR if that's a fine solution.

jplatte commented 3 months ago

I would assume adding a clippy::clone_on_ref_ptr to the #[allow(…)] attribute on this line would fix the problem. I can open a PR if that's a fine solution.

Sounds good!